[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bfd and cygpath

From: Peter Rosin
Subject: Re: bfd and cygpath
Date: Thu, 25 Apr 2013 08:52:05 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5

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

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
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:
> 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...


reply via email to

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