This is the mail archive of the
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 <firstname.lastname@example.org> wrote:
>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin <email@example.com> wrote:
>>> So, it appears that LT_PATH_LD does not like your ld? I'd look into
>> 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
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
The reason I ask is because your $LD result
hasn't been canonicalized. I'd expect it to be
but the canonicalized version is only assigned to $LD if $LD isn't set
BTW, have you played mount games that perhaps fools the naive c14n?
Hmm, I also see this:
case $host in
# 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` ;;
Does your $host match *-*-mingw*?
> I found this:
> configure:5654: checking for ld used by gcc
> configure:5721: result:
> configure:5728: checking if the linker
> 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
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...