libtool
[Top][All Lists]
Advanced

[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: Wed, 24 Apr 2013 22:01:12 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5

On 2013-04-24 18:29, NightStrike wrote:
> 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?

The way I read it, --with-gnu-ld means that libtool should look for
GNU ld (in $PATH, skipping past any other ld that doesn't pass
muster), it is not meant to force libtool into using some random ld
as if it was GNU ld.

So, it appears that LT_PATH_LD does not like your ld? I'd look into
that. Btw, is $GCC "yes"?

Cheers,
Peter




reply via email to

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