[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[kevin at teews dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482

Kevin Sweet <kevin at teews dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kevin at teews dot com

--- Comment #8 from Kevin Sweet <kevin at teews dot com> 2011-02-10 15:14:06 UTC ---
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!

[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[nicolas at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482

Nicolas Boulenguez <nicolas at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at debian dot org

--- Comment #9 from Nicolas Boulenguez <nicolas at debian dot org> ---
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.

[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[tromey at gcc dot gnu dot org]

------- Comment #7 from tromey at gcc dot gnu dot org  2009-08-09 00:09 -------
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")


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482

[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[steven at gcc dot gnu dot org]

------- Comment #6 from steven at gcc dot gnu dot org  2009-08-08 22:52 -------
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? 


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   GCC host triplet|i686-unknown-               |
                   |sysv5OpenUNIX8.0.0          |
 GCC target triplet|i686-unknown-               |
                   |sysv5OpenUNIX8.0.0          |
   Last reconfirmed|0000-00-00 00:00:00         |2009-08-08 22:52:57
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482

[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[aschorr at telemetry-investments dot com]

------- Comment #5 from aschorr at telemetry-investments dot com  2007-03-15 13:22 -------
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


-- 

aschorr at telemetry-investments dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aschorr at telemetry-
                   |                            |investments dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482

[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[tromey at gcc dot gnu dot org]

------- Comment #4 from tromey at gcc dot gnu dot org  2007-01-19 22:57 -------
> 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.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482

[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[maxim dot yegorushkin at gmail dot com]

------- Comment #3 from maxim dot yegorushkin at gmail dot com  2007-01-03 12:31 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482

[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[maxim dot yegorushkin at gmail dot com]

------- Comment #2 from maxim dot yegorushkin at gmail dot com  2007-01-02 16:38 -------
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.
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482

[Bug bootstrap/29482] libcpp/configure - no usable dependency style found

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-16 15:46 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482