[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bfd and cygpath

From: NightStrike
Subject: Re: bfd and cygpath
Date: Fri, 26 Apr 2013 01:58:12 -1000

On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin <address@hidden> wrote:
> On 2013-04-24 22:24, NightStrike wrote:
>> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike <address@hidden> wrote:
>>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin <address@hidden> wrote:
>>>> So, it appears that LT_PATH_LD does not like your ld? I'd look into
>>>> that.
>>> Where is the actual test that runs when that option is set?  I can't find 
>>> it.
> It's in the LT_PATH_LD macro, a loop is broken out of like this:
>       case `"$lt_cv_path_LD" -v 2>&1 </dev/null` in
>       *GNU* | *'with BFD'*)
>         test no != "$with_gnu_ld" && break
>         ;;
>       *)
>         test yes != "$with_gnu_ld" && break
>         ;;
>       esac
> But reading it more carefully, it appears as if $LD is not clobbered if 
> already
> set by the user (and if $LD is preset by the user I read it as if 
> --with-gnu-ld
> indeed forces libtool to treat $LD is GNU ld). Do you feed a preset $LD to
> configure? Does anything else in configure set $LD before the expansion of
> LT_PATH_LD runs?

I don't explicitly set LD in top level configure, no.  I thought it
was being set via the output of gcc -print-prog-name=ld, as per my
last post.  I could be wrong.

> The reason I ask is because your $LD result
> c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
> hasn't been canonicalized. I'd expect it to be
>         c:/mingw32/i686-w64-mingw32/bin/ld.exe
> but the canonicalized version is only assigned to $LD if $LD isn't set
> already.
> BTW, have you played mount games that perhaps fools the naive c14n?

I don't know what c14n is.  I'm not trying to play mount games, but I
am running in a hybrid wine environment.

> Hmm, I also see this:
>   case $host in
>   *-*-mingw*)
>     # gcc leaves a trailing carriage return which upsets mingw
>     ac_prog=`($CC -print-prog-name=ld) 2>&5 | tr -d '\015'` ;;
>   *)
>     ac_prog=`($CC -print-prog-name=ld) 2>&5` ;;
>   esac
> Does your $host match *-*-mingw*?

Yes, build==host==target==i686-w64-mingw32 using 32-bit wine on linux.

>> I found this:
>> configure:5654: checking for ld used by gcc
>> configure:5721: result:
>> c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
>> configure:5728: checking if the linker
>> (c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe)
>> is GNU ld
>> configure:5743: result: no
> The above is (partial) output from LT_PATH_LD.
>> So here's a problem...   It's getting that linker instead of just
>> using $CC because it grabbed the output of gcc -print-prog, which is
>> using a windows style path.
> Windows style pathnames shouldn't be a problem on MSYS. I assume you are
> on MSYS?

Nope.  wine.

> It's perhaps time to send the full config.log...

Ok, will try setting LD and will send with and without that.

>> What I don't understand is why it isn't just using gcc as the linker,
>> instead of ld.
> It's the way it has been done for a long time, I think originally bugs
> (bugs now long gone) caused libtool devs to sidestep the frontend when
> linking (instead of fixing upstream). And you are not the first to ask.
> I'm sure most would be happy to see this change. I'm also sure some
> will be upset by regressions...

This is probably a sure path to success.  Every piece of documentation
I've ever read on GCC says not to call ld directly.  How do we get
this changed?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]