[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
unmodified.
> 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.
- Re: bfd and cygpath, (continued)
- Re: bfd and cygpath, NightStrike, 2013/04/24
- Re: bfd and cygpath, NightStrike, 2013/04/24
- Re: bfd and cygpath, NightStrike, 2013/04/24
- Re: bfd and cygpath, Peter Rosin, 2013/04/24
- Re: bfd and cygpath, NightStrike, 2013/04/24
- Re: bfd and cygpath, NightStrike, 2013/04/24
- Re: bfd and cygpath, Peter Rosin, 2013/04/25
- Re: bfd and cygpath, NightStrike, 2013/04/26
- Re: bfd and cygpath, NightStrike, 2013/04/26
- Re: bfd and cygpath, Peter Rosin, 2013/04/26
- Re: bfd and cygpath,
NightStrike <=
- Re: bfd and cygpath, Peter Rosin, 2013/04/26
- Re: bfd and cygpath, Peter Rosin, 2013/04/26