This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: bfd and cygpath
- From: Peter Rosin <peda at lysator dot liu dot se>
- To: NightStrike <nightstrike at gmail dot com>
- Cc: Libtool List <libtool at gnu dot org>, binutils <binutils at sourceware dot org>
- Date: Thu, 25 Apr 2013 08:52:05 +0200
- 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>
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?
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?
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*?
> 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?
It's perhaps time to send the full config.log...
> 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...
Cheers,
Peter