On Wed, Apr 24, 2013 at 4:16 PM, NightStrike <nightstr...@gmail.com> wrote: > 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.
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" _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
