Re: bfd and cygpath

[NightStrike]

On Wed, Apr 24, 2013 at 12:17 PM, NightStrike <address@hidden> wrote:
> On Wed, Apr 24, 2013 at 11:55 AM, NightStrike <address@hidden> wrote:
>> On Wed, Apr 24, 2013 at 2:47 AM, Peter Rosin <address@hidden> wrote:
>>> On 2013-04-23 16:12, NightStrike wrote:
>>
>>>> I can't find it in upstream libtool, though, so can somebody update
>>>> libtool again?
>>>
>>> The only code branch in libtool.m4 that in the past did set the
>>> fix_srcfile_path variable can only be entered if libtool thinks
>>> that GNU ld is not in use.
>>>
>>> In libtool.m4, near the start of _LT_LINKER_SHLIBS, we have
>>>
>>>   case $host_os in
>>>   cygwin* | mingw* | pw32* | cegcc*)
>>>     # FIXME: the MSVC++ port hasn't been tested in a loooong time
>>>     # When not using gcc, we currently assume that we are using
>>>     # Microsoft Visual C++.
>>>     if test yes != "$GCC"; then
>>>       with_gnu_ld=no
>>>     fi
>>>     ;;
>>>
>>> So, either "$GCC" is not "yes", or with_gnu_ld ends up "no"
>>> somewhere else, otherwise you can't hit the below code branch.
>>
>> Thank you for this analysis!  Do you think setting the --with-gnu-ld
>> configure option will do the trick?  (I'm using gnu ld)
>>
>> I'll try it now and see what happens.
>
> At first crack, --with-gnu-ld does nothing to change the outcome.
> We're still trying to use cygpath and getting a cygpath not found
> error instead of using $(CYGPATH_W), which is still set to echo.
>
> Interestingly, with_gnu_ld="no" still appears in the bfd/libtool
> script.  Does the --with-gnu-ld option not do what I think it does?

Looks like it gets set right all the way through, until the very end
when libtool takes over:

# Whether we are building with GNU ld or not.
with_gnu_ld=$lt_with_gnu_ld

Why on earth does it do that?