Re: bfd and cygpath

[Peter Rosin <peda at lysator dot liu dot se>]

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