Re: building same source with different flag

[Ted Irons]

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 <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