This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bfd and cygpath


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:
>> On 2013-04-24 18:29, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 12:17 PM, NightStrike <nightstrike@gmail.com> wrote:
>>>> On Wed, Apr 24, 2013 at 11:55 AM, NightStrike <nightstrike@gmail.com> wrote:
>>>>> On Wed, Apr 24, 2013 at 2:47 AM, Peter Rosin <peda@lysator.liu.se> 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.

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

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.

What I don't understand is why it isn't just using gcc as the linker,
instead of ld.

>> Btw, is $GCC "yes"?
>
> Yes, twice in fact:
>
> config.status:GCC='yes'
> config.status:GCC="yes"


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]