This is the mail archive of the
mailing list for the binutils project.
Re: bfd and cygpath
- From: NightStrike <nightstrike at gmail dot com>
- To: Peter Rosin <peda at lysator dot liu dot se>
- Cc: binutils <binutils at sourceware dot org>, Libtool List <libtool at gnu dot org>
- Date: Wed, 24 Apr 2013 12:17:27 -0400
- Subject: Re: bfd and cygpath
- References: <CAF1jjLvtiySDHS7WqrNaSYA3sxqLk-wVzm=EQuPpORda72B5AA at mail dot gmail dot com> <CAF1jjLvsn8oy0D+=MFYDiON3UW+ocBTZT1G347RHGcCEt9fkDQ at mail dot gmail dot com> <51777FF9 dot 2020105 at lysator dot liu dot se> <CAF1jjLtfvAkqCnCKxGp95nzSHbo1zMTU_ccahQ=-SEujXfXQmg at mail dot gmail dot com>
On Wed, Apr 24, 2013 at 11:55 AM, NightStrike <email@example.com> wrote:
> On Wed, Apr 24, 2013 at 2:47 AM, Peter Rosin <firstname.lastname@example.org> 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
>> 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?