[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 06:51:53 -1000

On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin <address@hidden> wrote:
> On 2013-04-26 13:58, NightStrike wrote:
>> 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.
> I had a look in the binutils src (2.23.51) and its top level configure
> has this:
> # We must set the default linker to the linker used by gcc for the correct
> # operation of libtool.  If LD is not defined and we are using gcc, try to
> # set the LD default to the ld used by gcc.
> if test -z "$LD"; then
>   if test "$GCC" = yes; then
>     case $build in
>     *-*-mingw*)
>       gcc_prog_ld=`$CC -print-prog-name=ld 2>&1 | tr -d '\015'` ;;
>     *)
>       gcc_prog_ld=`$CC -print-prog-name=ld 2>&1` ;;
>     esac
>     case $gcc_prog_ld in
>     # Accept absolute paths.
>     [\\/]* | [A-Za-z]:[\\/]*)
>       LD="$gcc_prog_ld" ;;
>     esac
>   fi
> fi
> Notice that it does not canonicalize gcc_prog_ld prior to the assignment
> of LD (which is done in the LT_PATH_LD macro). I think this is what
> causes LD to have the value it has in the bfd configure. I notice that
> you are using a configure cache as well, which might me responsible for
> carrying the LD value over to bfd.

But if I set LD myself in the configure line, then it shouldn't
exercise this code and should pass the LD over to bfd configure

> But 
> c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe
> or c:/mingw32/i686-w64-mingw32/bin/ld.exe
> should be mear cosmetics (since you are not playing mount/symlink games).
> What do you get if you run:
> c:/mingw32/i686-w64-mingw32/bin/ld.exe -v </dev/null
> (which is what _LT_PATH_LD_GNU runs to determine if you are using GNU ld)

No such file or directory, which is to be expected.  It's a wine path.
 Gcc can execute that because gcc is running under wine.  But I can't
run that directly from a bash shell.

>>> 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.
> c14n -> canonicalization, like i18n and l10n.
>>> 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.
> Ok.
>>>> 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.
> You had LD=i686-w64-mingw32-gcc, which will not make libtool happy. You
> might try LD=i686-w64-mingw32-ld instead, but you shouldn't need to
> specify LD...

I'll try LD=i68...-ld, but libtool should really fix 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?
> Search me.  Sorry.

Darn.  I was hoping you had the inside track on libtool.

reply via email to

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