configure problem

configure problem

[Julian Bentayeb]

Hello!

We are getting the following messages:

cpp: fork: Interrupted system call (see attachment for full results).

when issuing the configure command to build SYSTEMC.

Our PATH point to the gcc2.95.2 bin and our LD_LIBRARY_PATH points to
the gcc2.95.2 lib.
We are running on solaris 2.6.

Any help you can give us is appreciated!

Thanks!

JULIAN BENTAYEB
ST Microelectronics
San Jose CAD
Phone: 408-451-8142
Fax: 408-452-7718
Email: julian.bentayeb@st.com

Re: configure problem

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On May 25, 2000, Julian Bentayeb <julian.bentayeb@st.com> wrote:

> cpp: fork: Interrupted system call (see attachment for full results).

What does the command `gcc -print-prog-name=cpp' print?  If it prints
just `cpp' or the pathname to `cpp' in the same directory that
contains `gcc', then your installation is broken: it should find it in
.../lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/.  Setting the environment
variable GCC_EXEC_PREFIX to that directory (note that trailing slash!)
may help.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: Configure problem

[Jim Wilson]

Zdenek Dvorak wrote:
pwd: /abuild/gcc-test/gcc/objdir/x86_64-unknown-linux-gnu/libobjc
Running configure in multilib subdir 32
pwd: /abuild/gcc-test/gcc/objdir/x86_64-unknown-linux-gnu
configure: loading cache ./config.cache
configure: error: `target_alias' was not set in the previous run
I can reproduce this even without multilibs on x86-linux
  cvs update
  mkdir objdir
  cd objdir
  ../configure
  make
  touch ../gcc/libobjc/Makefile.in
  make
The problem here is that the original sub configure happened from the 
toplevel Makefile, and a small number of variables are set in the 
environment before we call the sub configure.  The second configure 
happens from a sub-make, and a large number of variables 
(BASE_FLAGS_TO_PASS) are set in the environment when we call a sub-make. 
 configure notices when the value of precious variables differs on 
reconfigure, and gives an error.

We can fix the problem by adding the missing variables to the 
environment before calling sub configures.  See my April 15 change to 
the toplevel Makefile.tpl.

Why you are seeing this with a multilib build is not clear.  It should 
only happen on a re-configure, which should not be necessary with a 
build from scratch.  Maybe there is something wrong with dependencies 
that causes the re-configure.  If you look at your logs, I would think 
this is obvious, as libobjc would get configured more times than necessary.

If changing Makefile.tpl doesn't make this go away, then there must be 
something else wrong.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Configure problem

[Zdenek Dvorak]

Hello,

after my last merge of tree ssa to lno-branch, I am getting the
following error during build:

...
/bin/sh config.status
config.status: creating Makefile
config.status: executing default commands
Adding multilib support to Makefile in /abuild/gcc-test/gcc/libobjc
multidirs=32
with_multisubdir=
Running configure in multilib subdirs 32
pwd: /abuild/gcc-test/gcc/objdir/x86_64-unknown-linux-gnu/libobjc
Running configure in multilib subdir 32
pwd: /abuild/gcc-test/gcc/objdir/x86_64-unknown-linux-gnu
configure: loading cache ./config.cache
configure: error: `target_alias' was not set in the previous run
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and
start over
make[1]: *** [Makefile] Error 1
make[1]: Leaving directory
`/abuild/gcc-test/gcc/objdir/x86_64-unknown-linux-gnu/libobjc'
make: *** [all-target-libobjc] Error 2

This occurs on both multilib architectures I have access to (x86_64 and
ppc), with parallel build (both -j2 and -j4).  The problem I have with
debugging this is that I can only reproduce it in my automated tester
(running the same commands as it does in (as far as I can tell) the same
environment does not work).

I suppose it is some missing dependency that causes a conflict during
the parallel build, but I have no idea what to look for or how to debug
this.  Some advice?

Zdenek