Ted Irons <[EMAIL PROTECTED]> writes: [...] | Am using autoconf-2.5.2, automake-1.5b, libtool-1.4b | on an ix86 box run running Suse Linux with kernel-2.4.6. [...] | libohrnet_la_SOURCES = ascbin.cc | libohrnet_la_CXXFLAGS = -DHIGHER_ORDER_NET ${HBP_CXXFLAGS} | libohrnet_la_LDFLAGS = -version-info @PIPES_VERSION@ [...] | source='ascbin.cc' object='libhrnet_la-ascbin.lo' libtool=yes \ | depfile='.deps/libhrnet_la-ascbin.Plo' tmpdepfile='.deps/libhrnet_la-ascbin.TPlo' \ | depmode=gcc /bin/sh ../../../pipes-1.0/config/depcomp \ | /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H | -I. -I../../../pipes-1.0/tma/hbp.lib -I../.. -fpermissive |-I../../../pipes-1.0/tma/util.lib -I../../../pipes-1.0/tma/trff.lib -g -O2 -c -o |libhrnet_la-ascbin.lo `test -f ascbin.cc || echo |'../../../pipes-1.0/tma/hbp.lib/'`ascbin.cc | g++ -DHAVE_CONFIG_H -I. -I../../../pipes-1.0/tma/hbp.lib -I../.. -fpermissive |-I../../../pipes-1.0/tma/util.lib -I../../../pipes-1.0/tma/trff.lib -g -O2 -c |../../../pipes-1.0/tma/hbp.lib/ascbin.cc -Wp,-MD,.deps/libhrnet_la-ascbin.TPlo -fPIC |-DPIC | mv -f libhrnet_la-ascbin.o .libs/libhrnet_la-ascbin.o | mv: cannot stat `libhrnet_la-ascbin.o': No such file or directory | make[3]: *** [libhrnet_la-ascbin.lo] Error 1 [...]
I can reproduce your problem by manually setting compiler_c_o and compiler_o_lo to "no" in the libtool script generated for a pet-project. So ... 1) Libtool has decided at configure-time that you compiler cannot run with both `-c' and `-o'. No idea why. It seems bogus to me if you are using GCC. You should probably dig config.log for clues. 2) Therefore `libtool' strips `-o libhrnet_la-ascbin.lo' from the compilation command and assumes that the compiler will build an object file called after the source file. That source file is assumed to be the last argument of the compilation command. 3) However `libtool' is not called directly. Actually, `make' calls `depcomp' which in turn calls `libtool'. Since you have `gcc', `depcomp' is in `gcc' mode and has appended `-Wp,-MD,.deps/libhrnet_la-ascbin.TPlo' to the the compilation command in order to track dependencies. 4) This last argument is taken by `libtool' to be the source file :). It just strips the dirname (`-Wp,-Md,.deps/' !) and the extension (`.Tplo'), append `.o', and you get `libhrnet_la-ascbin.o', the object `libtool' thinks `gcc' will create. (It's funny to see that this behavior leads to a correct result if you do not use per-target CXXFLAGS; because the dependency option is then `-Wp,-MD,.deps/ascbin.TPlo' which `libtool' maps to `ascbin.o'.) 5) Finally the compilation command is run, ascbin.o is created, and libtool fail to move the resulting object because it looks for `libhrnet_la-ascbin.o' instead. As an immediate work-around, you can prevent `depcomp' to add this "fatal" last argument by configuring your package with --disable-dependency-tracking. However it would be better to find out why `gcc -c -o' doesn't work on your host. I can see two ways to fix this: either teach `depcomp' to stick `-Wc,' or `-Xcompiler' before dependency tracking options when running libtool (some depcomp modes such as aix already do that properly), or teach `libtool' to ignore options (`-*') when updating $srcfile. Which one seems more sensible? both? -- Alexandre Duret-Lutz