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
