Alexandre -
I have started to look into why g++ is
not accepting both -c and -o. Here is what I have
so far:
---------------------------------------------------------------
In configure.ac I have
...
ACX_CXXCOMPILE
AM_PROG_LIBTOOL
....
where ACX_CXXCOMPILE is
dnl ACX_CXXCOMPILE
dnl
dnl Checks for a CXX
dnl If CXX is g++ then set PERMISSIVE_FLAG.
dnl If CXX is CC on IRIX then setup CXXFLAGS.
dnl
AC_DEFUN(ACX_CXXCOMPILE,
[
AC_PROG_CXX(CC g++)
AC_PROG_CXXCPP
AC_REQUIRE([AC_CANONICAL_HOST])
AC_MSG_CHECKING(for CXX flags)
if test "$GXX" = yes; then
PERMISSIVE_FLAG="-fpermissive"
else
PERMISSIVE_FLAG=
fi
case $host in
*-*-irix6*)
if ! test "$GXX" = yes; then
acx_flags1="-n32 -ptused -LANG:ansi-for-init-scope=on "
acx_flags2="-OPT:Olimit=30000 -signed -G0 -fullwarn "
acx_flags3="-woff 1506,1682,1355,1314,1375,1209,1209,1681"
CXXFLAGS="$CXXFLAGS $acx_flags1 $acx_flags2 $acx_flags3"
fi
;;
esac
AC_SUBST(PERMISSIVE_FLAG)
AC_MSG_RESULT(${CXXFLAGS})
])
------------------------------------------------------------------------------------
The resulting configure has the lines
....
echo "$as_me:8119: checking if $compiler supports -c -o file.$ac_objext" >&5
echo $ECHO_N "checking if $compiler supports -c -o file.$ac_objext... $ECHO_C" >&6
if test "${lt_cv_prog_compiler_c_o_CXX+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
lt_cv_prog_compiler_c_o_CXX=no
$rm -r conftest 2>/dev/null
mkdir conftest
cd conftest
mkdir out
save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -o out/conftest2.$ac_objext"
echo "$lt_simple_compile_test_code" > conftest.$ac_ext
# According to Tom Tromey, Ian Lance Taylor reported there are C compilers
# that will create temporary files in the current directory regardless of
# the output directory. Thus, making CWD read-only will cause this test
# to fail, enabling locking or at least warning the user not to do parallel
# builds.
chmod -w .
if (eval $ac_compile 2>out/conftest.err) && test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings
if test -s out/conftest.err; then
# Append any errors to the config.log.
cat out/conftest.err 1>&5
else
lt_cv_prog_compiler_c_o_CXX=yes
fi
fi
CFLAGS="$save_CFLAGS"
chmod u+w .
$rm conftest* out/*
rmdir out
cd ..
rmdir conftest
$rm conftest*
fi
---------------------------------------------------------------------------------------
If I change the CFLAGS to CXXFLAGS in configure the configure output
gives "g++ supports -c -o file.o ... yes"; otherwise the answer given is no.
Incidentally, configure does a prior check of gcc with -c and -o, and that
passes.
I have no idea why the configure check is using CFLAGS instead of
CXXFLAGS. I changed the CXXFLAGS in ACX_CXXCOMPILE to
AM_CXXFLAGS, but that made no difference.
Thanks again for your help,
- Ted
Alexandre Duret-Lutz wrote:
> 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
