automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: building same source with different flag


From: Alexandre Duret-Lutz
Subject: Re: building same source with different flag
Date: 27 Dec 2001 09:29:55 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1

Ted Irons <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]