libtool-1.4.2 (part II)

[Carlo Wood]

FYI,

in my previous mail I reported a bug in libtool.
The following is additional information regarding that bug report.

To recall, the following command failed:

$ source='ecc_rng.cc' object='libecc_la-ecc_rng.lo' libtool=yes \
  depfile='.deps/libecc_la-ecc_rng.Plo' 
tmpdepfile='.deps/libecc_la-ecc_rng.TPlo' \
  depmode=gcc3 /bin/sh ./depcomp \
  /bin/sh ./libtool --mode=compile g++ -DHAVE_CONFIG_H  -I./include -I./include 
  -g -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings 
-Werror  -c -o libecc_la-ecc_rng.lo `test -f ecc_rng.cc || echo './'`ecc_rng.cc
g++ -DHAVE_CONFIG_H -I./include -I./include -g -pipe -Wall -Woverloaded-virtual 
-Wundef -Wpointer-arith -Wwrite-strings -Werror -c ecc_rng.cc -MT 
libecc_la-ecc_rng.lo -MD -MP -MF .deps/libecc_la-ecc_rng.TPlo  -fPIC -DPIC
mv -f libecc_la-ecc_rng.o libecc_la-ecc_rng.lo
mv: cannot stat `libecc_la-ecc_rng.o': No such file or directory


Now please note that when only executing the 'libtool' part
we get:

$ /bin/sh ./libtool --mode=compile g++ -DHAVE_CONFIG_H  -I./include -I./include 
  -g -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings 
-Werror  -c -o libecc_la-ecc_rng.lo `test -f ecc_rng.cc || echo './'`ecc_rng.cc
g++ -DHAVE_CONFIG_H -I./include -I./include -g -pipe -Wall -Woverloaded-virtual 
-Wundef -Wpointer-arith -Wwrite-strings -Werror -c ecc_rng.cc -fPIC -DPIC
mv -f ecc_rng.o libecc_la-ecc_rng.lo

and no error occurs.
The difference is that './depcomp' is adding "-MT libecc_la-ecc_rng.lo -MD -MP 
-MF .deps/libecc_la-ecc_rng.TPlo"
to the command line parameters.

And indeed, when I manually add that to the libtool line,
we get:

$ /bin/sh ./libtool --mode=compile g++ -DHAVE_CONFIG_H  -I./include -I./include 
  -g -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings 
-Werror  -c -o libecc_la-ecc_rng.lo `test -f ecc_rng.cc || echo './'`ecc_rng.cc 
-MT libecc_la-ecc_rng.lo -MD -MP -MF .deps/libecc_la-ecc_rng.TPlo
g++ -DHAVE_CONFIG_H -I./include -I./include -g -pipe -Wall -Woverloaded-virtual 
-Wundef -Wpointer-arith -Wwrite-strings -Werror -c ecc_rng.cc -MT 
libecc_la-ecc_rng.lo -MD -MP -MF .deps/libecc_la-ecc_rng.TPlo  -fPIC -DPIC
mv -f libecc_la-ecc_rng.o libecc_la-ecc_rng.lo
mv: cannot stat `libecc_la-ecc_rng.o': No such file or directory

This time 'libtool' executed the command
"g++ -DHAVE_CONFIG_H -I./include -I./include -g -pipe -Wall 
-Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings -Werror \
  -c ecc_rng.cc -MT libecc_la-ecc_rng.lo -MD -MP -MF 
.deps/libecc_la-ecc_rng.TPlo  -fPIC -DPIC"

which, when we execute it manually, results in an
output file with the name "ecc_rng.o" (which is correct
because no '-o' was given).

Without the by './depcomp' added "-MT libecc_la-ecc_rng.lo -MD -MP -MF 
.deps/libecc_la-ecc_rng.TPlo"
the command
"g++ -DHAVE_CONFIG_H -I./include -I./include -g -pipe -Wall 
-Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings -Werror \
 -c ecc_rng.cc -fPIC -DPIC"

ALSO results in an output file "ecc_rng.o" (of course).

The problem is thus that in the first case
the 'mv' is trying to move "libecc_la-ecc_rng.o" instead
of what is normal ("ecc_rng.o").

The reason that 'libtool' suddenly tries to move "libecc_la-ecc_rng.o"
is because of the extra parameter "-MF .deps/libecc_la-ecc-rng.TPlo".
For example, when we add manually the nonsense parameter "-MF .deps/foobar.ext"
we get:

$ /bin/sh ./libtool --mode=compile g++ -DHAVE_CONFIG_H  -I./include -I./include 
  -g -pipe -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings 
-Werror  -c -o libecc_la-ecc_rng.lo `test -f ecc_rng.cc || echo './'`ecc_rng.cc 
-MD -MF .deps/foobar.ext
g++ -DHAVE_CONFIG_H -I./include -I./include -g -pipe -Wall -Woverloaded-virtual 
-Wundef -Wpointer-arith -Wwrite-strings -Werror -c ecc_rng.cc -MD -MF 
.deps/foobar.ext  -fPIC -DPIC
mv -f foobar.o libecc_la-ecc_rng.lo
mv: cannot stat `foobar.o': No such file or directory

Conclusion
----------

The 'libtool' script of libtool-1.4.2 has the bug that
a commandline parameter "-MF name.ext" has influence on
what libtool thinks is the name of the output object file,
trying to 'mv' "name.o" to whatever the name *should* be.

-- 
Carlo Wood <address@hidden>