On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin <p...@lysator.liu.se> wrote: > On 2013-04-24 22:24, NightStrike wrote: >> 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: >>>> 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. > > It's in the LT_PATH_LD macro, a loop is broken out of like this: > > case `"$lt_cv_path_LD" -v 2>&1 </dev/null` in > *GNU* | *'with BFD'*) > test no != "$with_gnu_ld" && break > ;; > *) > test yes != "$with_gnu_ld" && break > ;; > esac > > But reading it more carefully, it appears as if $LD is not clobbered if > already > set by the user (and if $LD is preset by the user I read it as if > --with-gnu-ld > indeed forces libtool to treat $LD is GNU ld). Do you feed a preset $LD to > configure? Does anything else in configure set $LD before the expansion of > LT_PATH_LD runs?
I don't explicitly set LD in top level configure, no. I thought it was being set via the output of gcc -print-prog-name=ld, as per my last post. I could be wrong. > The reason I ask is because your $LD result > > c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe > hasn't been canonicalized. I'd expect it to be > c:/mingw32/i686-w64-mingw32/bin/ld.exe > but the canonicalized version is only assigned to $LD if $LD isn't set > already. > > BTW, have you played mount games that perhaps fools the naive c14n? I don't know what c14n is. I'm not trying to play mount games, but I am running in a hybrid wine environment. > Hmm, I also see this: > > case $host in > *-*-mingw*) > # gcc leaves a trailing carriage return which upsets mingw > ac_prog=`($CC -print-prog-name=ld) 2>&5 | tr -d '\015'` ;; > *) > ac_prog=`($CC -print-prog-name=ld) 2>&5` ;; > esac > > Does your $host match *-*-mingw*? Yes, build==host==target==i686-w64-mingw32 using 32-bit wine on linux. >> 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 > > The above is (partial) output from LT_PATH_LD. > >> 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. > > Windows style pathnames shouldn't be a problem on MSYS. I assume you are > on MSYS? Nope. wine. > It's perhaps time to send the full config.log... Ok, will try setting LD and will send with and without that. >> What I don't understand is why it isn't just using gcc as the linker, >> instead of ld. > > It's the way it has been done for a long time, I think originally bugs > (bugs now long gone) caused libtool devs to sidestep the frontend when > linking (instead of fixing upstream). And you are not the first to ask. > I'm sure most would be happy to see this change. I'm also sure some > will be upset by regressions... This is probably a sure path to success. Every piece of documentation I've ever read on GCC says not to call ld directly. How do we get this changed? _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
