This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: bfd and cygpath
- From: NightStrike <nightstrike at gmail dot com>
- To: Peter Rosin <peda at lysator dot liu dot se>
- Cc: Libtool List <libtool at gnu dot org>, binutils <binutils at sourceware dot org>
- Date: Fri, 26 Apr 2013 06:51:53 -1000
- Subject: Re: bfd and cygpath
- References: <CAF1jjLvtiySDHS7WqrNaSYA3sxqLk-wVzm=EQuPpORda72B5AA at mail dot gmail dot com> <CAF1jjLvsn8oy0D+=MFYDiON3UW+ocBTZT1G347RHGcCEt9fkDQ at mail dot gmail dot com> <51777FF9 dot 2020105 at lysator dot liu dot se> <CAF1jjLtfvAkqCnCKxGp95nzSHbo1zMTU_ccahQ=-SEujXfXQmg at mail dot gmail dot com> <CAF1jjLuZ5zSB+y_JFA5YH0_Q3N1LG9=-yFoWsz4R9iugVsc1GA at mail dot gmail dot com> <CAF1jjLvtL_8ZUyreQstgUhU9zoDqpxFs=dwmyyrne52FKg6WZA at mail dot gmail dot com> <51783A08 dot 4050906 at lysator dot liu dot se> <CAF1jjLuVMg-AZ8na6OYG2cvenv2k5PDnfxXhHGFZLisNkdQteg at mail dot gmail dot com> <CAF1jjLv=f6dwM1cvU02Mrbe0fvK+w=EHJ+zQbdt7zjaJfhbpCQ at mail dot gmail dot com> <5178D295 dot 50603 at lysator dot liu dot se> <CAF1jjLssvtgbEMrtNFevMywrXgjniC1yc3gn_x6vh-U+RNu_hw at mail dot gmail dot com> <517A89C8 dot 6080000 at lysator dot liu dot se>
On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin <peda@lysator.liu.se> wrote:
> On 2013-04-26 13:58, NightStrike wrote:
>> On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin <peda@lysator.liu.se> wrote:
>>> On 2013-04-24 22:24, NightStrike wrote:
>>>> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike <nightstrike@gmail.com> wrote:
>>>>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin <peda@lysator.liu.se> 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.