[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bfd and cygpath
From: |
NightStrike |
Subject: |
Re: bfd and cygpath |
Date: |
Wed, 24 Apr 2013 16:16:06 -0400 |
On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin <address@hidden> wrote:
> 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.
Ok.
> 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.
> Btw, is $GCC "yes"?
Yes, twice in fact:
config.status:GCC='yes'
config.status:GCC="yes"
- bfd and cygpath, NightStrike, 2013/04/23
- Re: bfd and cygpath, NightStrike, 2013/04/23
- Re: bfd and cygpath, Peter Rosin, 2013/04/24
- Re: bfd and cygpath, NightStrike, 2013/04/24
- Re: bfd and cygpath, NightStrike, 2013/04/24
- Re: bfd and cygpath, NightStrike, 2013/04/24
- Re: bfd and cygpath, Peter Rosin, 2013/04/24
- Re: bfd and cygpath,
NightStrike <=
- Re: bfd and cygpath, NightStrike, 2013/04/24
- Re: bfd and cygpath, Peter Rosin, 2013/04/25
- Re: bfd and cygpath, NightStrike, 2013/04/26
- Re: bfd and cygpath, NightStrike, 2013/04/26
- Re: bfd and cygpath, Peter Rosin, 2013/04/26
- Re: bfd and cygpath, NightStrike, 2013/04/26
- Re: bfd and cygpath, Peter Rosin, 2013/04/26
- Re: bfd and cygpath, Peter Rosin, 2013/04/26