------- Comment #7 from rwild at gcc dot gnu dot org 2008-03-31 22:26 ------- While I still haven't had a chance to look at this, here's what I can gather from the comments or say about libtool:
First, when to-be-installed programs are created using libtool, and they link against uninstalled libtool libraries, then typically, a binary usable in the build tree may not be usable in the install tree and vice versa. Consequently, there are two of them, plus a wrapper script or binary. libtool now has two modes, fast-install and not, to prefer one-shot builds (where, if possible, the to-be-installed one is built by default, in .libs/$name, and upon execution of $name, an uninstalled binary is created in .libs/lt-$name). The fact that ld/Makefile.am contains noinst_PROGRAMS = ld-new (and thus can be construed to not ever be installed) is not passed from automake to libtool. And in this case, ld-new *is* installed, by install-exec-local, so passing -no-install to libtool would be wrong for some systems. You should be able to prioritise the creation of the uninstalled binary with ld_new_LDFLAGS = -no-fast-install but note that then, upon 'make install' a relink may be performed by libtool. I'm not sure whether that would be a better solution than the patch from comment #1 (and I have yet to try it myself). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
