Dependency creation fails for libcpp on OpenUnix 8.5. Surprisingly enough the previous phases of the gcc bootstrap work well enough and also seemed to do some dependency work. The cc on Caldera OpenUnix 8.5 can generate dependencies but it's not used for this purpose. Here is the man : -H Causes the pathnames of all files included to be printed, one per line, on the standard error output. I'm not a shell wizzard but I guess something like the following should be added to depcomp (I mean - the following does NOT work :) ). sco) cc -c -H "$object" 2>"$tmpdepfile" stat=$? cat $tmpdepfile if test $stat -eq 0; then : else rm -f "$tmpdepfile" exit $stat fi mv "$tmpdepfile" "$depfile" ;; I know the stderr may not available for the purpose. May be someone more familiar with these scripts can do the trick? Thank you, Mircea P.S.1 Here's the uname -a : OpenUNIX T114p 5 8.0.0 i386 x86at Caldera UNIX_SVR5 P.S.2 May be mp4 could be made to generate these dependencies so this whole script collection becomes unneeded?
The configure check in libcpp is based on automake's code. Do you know if they support SCO's cc dependencies yet? Note you should also read README.SCO.
I'm having a similar problem on Linux Fedora Core 5. Is there any quick way to fix it? I am new to autoconf and would appreciate any hints. Here is the output: $ make CC=/usr/local/N/Linux2.6/amd64/3.3.6/bin/gcc CXX=/usr/local/N/Linux2.6/amd64/3.3.6/bin/g++ make[1]: Entering directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64' make[2]: Entering directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/libiberty' /M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/libiberty/testsuite make[3]: Entering directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/libiberty/testsuite' make[2]: Leaving directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/libiberty' make[2]: Entering directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/fixincludes' make[2]: Entering directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/intl' /M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/libiberty make[2]: Entering directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/libiberty' /M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/libiberty/testsuite make[3]: Entering directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/libiberty/testsuite' make[2]: Leaving directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/libiberty' /M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/fixincludes make[2]: Entering directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64/build-x86_64-unknown-linux-gnu/fixincludes' Configuring in ./libcpp configure: loading cache ./config.cache checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking for x86_64-unknown-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for x86_64-unknown-linux-gnu-ranlib... ranlib checking for aclocal... aclocal checking for autoconf... autoconf checking for autoheader... autoheader checking whether gcc supports -W... yes checking whether gcc supports -Wall... yes checking whether gcc supports -Wwrite-strings... yes checking whether gcc supports -Wstrict-prototypes... yes checking whether gcc supports -Wmissing-prototypes... yes checking whether gcc supports -Wold-style-definition... yes checking whether gcc supports -Wmissing-format-attribute... yes checking whether gcc supports -pedantic -Wno-long-long... yes checking dependency style of gcc... none configure: error: no usable dependency style found make[1]: *** [configure-libcpp] Error 1 make[1]: Leaving directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/Linux2.6/amd64' make: *** [all] Error 2 $ rpm -q autoconf autoconf-2.59-7 $ uname -a Linux xxx 2.6.17-1.2157_FC5 #1 SMP Tue Jul 11 22:53:56 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux (In reply to comment #1) > The configure check in libcpp is based on automake's code. Do you know if they > support SCO's cc dependencies yet? > Note you should also read README.SCO. >
(In reply to comment #2) > I'm having a similar problem on Linux Fedora Core 5. Is there any quick way to > fix it? I am new to autoconf and would appreciate any hints. > > Here is the output: The same problem with Solaris 10: ... checking whether gcc supports -pedantic -Wno-long-long... yes checking dependency style of gcc... none configure: error: no usable dependency style found make[1]: *** [configure-libcpp] Error 1 make[1]: Leaving directory `/M/codebase/local/src/gcc/gcc-4.1.1-obj/SunOS5.10/amd64' make: *** [all] Error 2 $ uname -a SunOS xxx 5.10 Generic_118855-15 i86pc i386 i86pc Solaris
> checking dependency style of gcc... none This is a weird message (from comment #2 and comment #3). It suggests to me that something else is going on -- something unrelated to the original bug filed in this PR. For this perhaps you could look in config.log to see what has gone wrong. As to the original PR -- I think fixes to depcomp should be handled upstream, in Automake. Also, libcpp should be changed to accept --disable-dependency-tracking, so that odd cases like this can be more easily worked around. Some users just want to do a single build and do not really need dependencies.
FYI, I had this same problem trying to build gcc-4.1.2 on Solaris 8. After a lot of experimentation, I found that it could be solved by changing my PATH so that any invocations of 'make' will actually result in the execution of gnu make, and not the bundled solaris make. It seems that just running the toplevel 'gmake bootstrap' with gnu make is not sufficient: there are embedded calls to 'make' down below, and you need to have your PATH configured in such a way that these calls to 'make' will end up running gnu make. Once I made this change, I was able to complete 'make bootstrap' with no problems at all. However, for some reason I was unable to chase down, 'make install' still failed with gcc-4.1.2. But this bug must have been fixed shortly after the release of gcc-4.1.2, because I was able to build and install a gcc-4.1.3 prerelease snapshot from 20070312 with no problems at all (given that 'make' is now resolving to gnu make). I hope this helps. Regards, Andy
Obviously something experienced by more than one user, on more than one platform. Tom, can you make a guess about what is wrong based on the suggested work-around of comment #5?
The earlier comments should probably first be investigated by looking in config.log. (Except the original comment which sounds like a missing feature in depcomp -- that should go upstream to Automake.) Comment #5 sounds like either a place in a Makefile that invokes make rather than $(MAKE); or perhaps a bug in GNU make (if an instance of $(MAKE) invokes make from $PATH rather than the same executable that is running). It is hard to be sure. This could also be caused if $(MAKE) is referenced through a variable; in this case the rule ought to start with a '+'. See (info "(make)MAKE Variable")
I had the same error building 4.5.2. In may case it was because I had a script called 'env' in my path before /bin/env. This cause "env $depcmd" to produce erroneous results. Basically, the lesson here is to build with minimum changes to the default path and environment!
Hello. I had the failure with GCC-10.2.1, only when running `autoreconf -f -i . fixincludes gcc subdirs...` before `./configure`. For each subdir in turn, autoreconf checks if the subdirectory uses libtool or automake. If so, it installs depcomp in . (../ from the subdir), else removes ./depcomp (breaking the build of other subdirectories). Changing the order of autoreconf arguments so that the last one depends on automake fixed the problem for me. I am not sure if this is a bug, or where to report it, but documenting the work-around here may be useful to other GCC users.