Re: bfd and cygpath

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

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 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)


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

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

Cheers,
Peter