On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin <p...@lysator.liu.se> wrote: > On 2013-04-24 18:29, NightStrike wrote: >> On Wed, Apr 24, 2013 at 12:17 PM, NightStrike <nightstr...@gmail.com> wrote: >>> On Wed, Apr 24, 2013 at 11:55 AM, NightStrike <nightstr...@gmail.com> wrote: >>>> On Wed, Apr 24, 2013 at 2:47 AM, Peter Rosin <p...@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. > Btw, is $GCC "yes"? Yes, twice in fact: config.status:GCC='yes' config.status:GCC="yes" _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
