On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin <p...@lysator.liu.se> wrote: > On 2013-04-26 13:58, NightStrike wrote: >> 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. > > I had a look in the binutils src (2.23.51) and its top level configure > has this: > > # We must set the default linker to the linker used by gcc for the correct > # operation of libtool. If LD is not defined and we are using gcc, try to > # set the LD default to the ld used by gcc. > if test -z "$LD"; then > if test "$GCC" = yes; then > case $build in > *-*-mingw*) > gcc_prog_ld=`$CC -print-prog-name=ld 2>&1 | tr -d '\015'` ;; > *) > gcc_prog_ld=`$CC -print-prog-name=ld 2>&1` ;; > esac > case $gcc_prog_ld in > # Accept absolute paths. > [\\/]* | [A-Za-z]:[\\/]*) > LD="$gcc_prog_ld" ;; > esac > fi > fi > > Notice that it does not canonicalize gcc_prog_ld prior to the assignment > of LD (which is done in the LT_PATH_LD macro). I think this is what > causes LD to have the value it has in the bfd configure. I notice that > you are using a configure cache as well, which might me responsible for > carrying the LD value over to bfd.
But if I set LD myself in the configure line, then it shouldn't exercise this code and should pass the LD over to bfd configure unmodified. > But > c:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe > or c:/mingw32/i686-w64-mingw32/bin/ld.exe > should be mear cosmetics (since you are not playing mount/symlink games). > > What do you get if you run: > > c:/mingw32/i686-w64-mingw32/bin/ld.exe -v </dev/null > > (which is what _LT_PATH_LD_GNU runs to determine if you are using GNU ld) No such file or directory, which is to be expected. It's a wine path. Gcc can execute that because gcc is running under wine. But I can't run that directly from a bash shell. >>> 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. > > c14n -> canonicalization, like i18n and l10n. > >>> 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. > > Ok. > >>>> 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. > > You had LD=i686-w64-mingw32-gcc, which will not make libtool happy. You > might try LD=i686-w64-mingw32-ld instead, but you shouldn't need to > specify LD... I'll try LD=i68...-ld, but libtool should really fix 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? > > Search me. Sorry. Darn. I was hoping you had the inside track on libtool. _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
