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? _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
