Re: egcs-1.1.2 build/test results for i586-linux-gnu

[Joseph Parmelee <jparmele at wildbear dot com>]

On Mon, 22 Mar 1999, Manfred Hollstein wrote:

> On Sat, 20 March 1999, 17:39:45, jparmele@wildbear.com wrote:
> 
>  > 
>  > On Sat, 20 Mar 1999, Manfred Hollstein wrote:
>  > 
>  > >  > "make install" installs libg2c.a and symbolic links libg++.so and libg++.a
>  > >  > in /usr/i586-linuxglibc2/lib/gcc-lib/i586-linuxglibc2 instead of in
>  > >  > /usr/i586-linuxglibc2/lib/gcc-lib/i586-linuxglibc2/egcs-2.91.66.  Our
>  > >  > install shell script moves them after installation.
> 
> Actually, the libg++ stuff should be installed into $(libsubdir)
> or below $(libdir) depending on whether you specified
> --enable-version-specific-runtime-libs when running configure.
> The proper value for "libsubdir" is emitted based on data/files
> found in the gcc subdirectory of the tree; did you perhaps remove
> that before you configured the runtime libs? Anyway, please read
> my advice below.
> 

You are right.  That is exactly what happened.  I deleted the gcc
subdirectory and replaced it with a blank to make all the recompiling stop
while I was trying to work on the libraries.  This is another example of the
problem with this whole general approach.  Why should the library builds
depend on having first done the compiler builds?  That is what wasted so
much of our precious time.  Surely this directory information can be
generated by the library build process without requiring a complete compiler
build.


>  > 
>  > > How did you actually call 1. configure and 2. make?
>  > 
>  > I will not burden you with all the explicit details of how we built the
>  > cross-development tools. This is a process that we have done before and
>  > which went pretty much as expected.  We then used the cross-development
>  > tools to build native development tools.  This process also worked as
>  > expected, with the usual minor confusions.  The gcc produced by this process
>  > passed its tests.  At that point it was impossible to test the other
>  > compilers as their libraries did not yet exist.  This set of native
>  > development tools was installed under the alternate prefix
>  > /usr/i586-linuxglibc2.
>  > 
>  > I have carefully inspected the output of running the installed gcc and g++
>  > with the -v and -Wl,--verbose options to insure that the libraries
>  > (including libgcc.a), startup files, and headers are being picked up from
>  > the right places.  This is a major potential source of problems, as we are
>  > well aware.  So long as the "-isystem /usr/i586-linuxglibc2/include" option
>  > is specifically included in the command line, the built-in search paths in
>  > the installed compiler drivers work correctly to find the pieces.  So,
>  > basically, all of that appears to be working as expected.
> 
> I still would like to know how you built the CROSS compiler, i.e.
> 
>   1. how _exactly_ did you call configure?
>   2. how _exactly_ did you call "make" and "make install"?
> 
> I'm afraid, your "cross" compiler is still using "/usr/include" as
> a default system include directory, which a cross compiler isn't
> allowed to do.

The objective of the process is to build a cross-into for glibc from libc5,
not a cross compiler.  Please understand that the problems I am reporting do
not involve the cross compiler in any way.  It is gone.  It has done its
thing and has literally been erased from the system so that it cannot be
accidentally called.  Its sole function was to produce a bootstrap compiler
that was recognized by configure as "native" (that is, producing glibc-using
code) so that egcs would bootstrap a full set of *native* glibc compilers
from it.

The compilers installed in /usr/i586-linuxglibc2/bin are *native* compilers
that use glibc directly, and if you don't tell them otherwise they most
certainly *will* use /usr/include.  After all, they think they are the
native compilers on the system.  They must be persuaded to take their
headers from /usr/i586-linuxglibc2/include instead, thus the -isystem
option.  Their built-in search paths cause them to correctly find the
startup files and libraries, so no other system directory options are
necessary.  I don't know why the include search directory wasn't also built
in, but it appears not to be.  The g++ include directory 
/usr/i586-linuxglibc2/include/g++ however is built in.  This is a minor
inelegance, though it would be nice to fix it.


> 
>  > 
>  > The problems that concern us relate to building libg2c, libg++, and
>  > particularly libstdc++.  The scripts below deal only with that part of the
>  > process.  At the time they are run, the native gcc, g++, binutils, glibc and
>  > its header files are already installed under /usr/i586-linuxglibc2/ in the
>  > bin, lib, and include subdirectories.
> 
> Why are you trying to build the stuff separately? Have you tried to
> build the whole package using something like:
> 
>  $ ../egcs-1.1.2/configure --prefix=/usr/i586-linuxglibc2
>  $ make cross
>  $ make install
> 

That will produce and install a cross compiler (you need to add --target of
course).  That's the first step.

If you want to use that cross compiler to bootstrap a native build, though,
you encounter the problem that the make scripts don't expect the results of
a cross-compilation to be executed on the build machine, and they don't
expect a cross-compiler to be executed on the target machine.  In order to
make this work, you need two separate operations so that the configure
believes it is running the first operation on the build machine, and the
second operation on the target machine, where it is happy to just bootstrap
gcc using the cross-compiler for the boot.  It doesn't know, and it doesn't
care that this compiler is actually linked to libc5.  Its behavior to the
configure is entirely indistinguishable from a native compiler, so the
process produces a real native compiler in the second operation.

As I indicated earlier, the compiler builds worked fine; our problems were
with the C++ library builds.


> I've been doing this for a long time now on several systems without
> any problems.
> 
> Your attempt to build the whole tree divided into several pieces
> results in e.g. missing or even wrong environment variables defined
> passed/not passed etc.  egcs's configure machinery is fairly complex
> and should not be "undermined".

If I hadn't separated the functionality here, we would probably still be
waiting for this mess to compile gcc yet again.  This is a bad design.  It
wastes precious time.  Please fix it.


> 
>  > 
>  > The configure script do-config.egcs-1.1.2 follows.  It resides in and is run
>  > from the main build directory, which is a peer to the egcs-1.1.2 directory.
>  > 
>  > CC=/usr/i586-linuxglibc2/bin/gcc \
>  > CFLAGS="-g -O3 -isystem /usr/i586-linuxglibc2/include" \
>  > CXX=/usr/i586-linuxglibc2/bin/g++ \
>  > CXXFLAGS="-g -O3 -isystem /usr/i586-linuxglibc2/include" \
>  > LIBCXXFLAGS_FOR_TARGET="-g -O3 -isystem /usr/i586-linuxglibc2/include" \
>  > AR=/usr/i586-linuxglibc2/bin/ar \
>  > NM=/usr/i586-linuxglibc2/bin/nm \
>  > RANLIB=/usr/i586-linuxglibc2/bin/ranlib \
>  > LD=/usr/i586-linuxglibc2/bin/ld \
>  > PATH=/usr/i586-linuxglibc2/bin:${PATH} \
>  > ../egcs-1.1.2/configure -v --prefix=/usr/i586-linuxglibc2/ \
>  > --enable-shared --host=i586-linuxglibc2
>  > ./do-make.egcs-1.1.2 configure-target-libg++
>  > ln -sf /usr/i586-linuxglibc2/include/regex.h i586-linuxglibc2/libg++/src/rx.h
>  > 
>  > 
>  > The make script do-make.egcs-1.1.2 follows.  Also resides in and is run from
>  > the main build directory:
>  > 
>  > make \
>  > CC=/usr/i586-linuxglibc2/bin/gcc \
>  > CFLAGS="-g -O3 -isystem /usr/i586-linuxglibc2/include" \
>  > CXX=/usr/i586-linuxglibc2/bin/g++ \
>  > CXXFLAGS="-g -O3 -isystem /usr/i586-linuxglibc2/include" \
>  > LIBCXXFLAGS_FOR_TARGET="-g -O3 -isystem /usr/i586-linuxglibc2/include" \
>  > AR=/usr/i586-linuxglibc2/bin/ar \
>  > NM=/usr/i586-linuxglibc2/bin/nm \
>  > RANLIB=/usr/i586-linuxglibc2/bin/ranlib \
>  > LD=/usr/i586-linuxglibc2/bin/ld \
>  > PATH=/usr/i586-linuxglibc2/bin:${PATH} \
>  > "$@"
>  > 
>  > 
>  > > 
>  > >  > 
>  > >  > libg++ configure sets a symbolic link from src/rx.h to /usr/include/rx.h,
>  > >  > which is a libc5 header in our configuration.
>  > > 
>  > > 
>  > >  > This had to be overridden in
>  > >  > a script file to point the link at /usr/i586-linuxglibc2/include/regex.h to
>  > >  > get libg++ to pick up the new headers.  Otherwise, as expected, libg++
>  > >  > builds but crashes totally on execute tests.  Our configure script first
>  > >  > runs configure, then makes the configure-target-libg++ target, then corrects
>  > >  > the errant link which that configure produces.
>  > >  > 
>  > 
>  > > This is indicating you're using a wrong CC/CXX when calling configure.
>  > 
>  > Well, you see it above.
> 
> I'm hoping, you are now understanding, why this is failing (a CROSS compiler
> will NOT look into /usr/include).
> 
>  > Note that the path business was required because
>  > the script insisted on using "ar" instead of $(AR) somewhere.  I think there
>  > were several instances of this, and also involving the test process which
>  > sometimes appeared to ignore $(CC) and insisted on "gcc".  These don't cause
>  > a problem unless you're trying to build out of the main directories, like we
>  > are, but clearly these should be corrected.  Anyway, the PATH thing provided
>  > a work-around for those cases where the explicit overrides were ignored.
>  > 
>  > BTW, I also tried all possible combinations including --target and --build,
>  > None of that had any effect.  But without either --host or --build, the
>  > configure naturally assumes that it is a libc5 system, as expected.
> 
> Please also try the simple solution I suggested above.
>  > 
>  > I forgot to mention in my original post that after the link was corrected,
>  > libg++ built and passed all its tests.
>  > 
> 
> Puuh, good, even that worked ;-)
>  > 
>  > >  > It really would be much more convenient to do all the configures at the
>  > >  > outset so that problems with the Makefiles can be seen and corrected before
>  > >  > a lot of compile time is burned.  This one change would have saved me
>  > >  > personally at least a week in this whole process.  This "make it all at
>  > >  > once" thing tries to be too smart for its own good.  It ends up being a real
>  > >  > nuisance when something doesn't work as expected.
>  > > 
>  > > I wouldn't say, the scripts are fool-proof, but most of the time
>  > > such errors occur in "home-brew" mixed Linux/GNU systems with more than
>  > > one libc but not the proper cross compilers.
>  > 
>  > I vigorously stand behind my original statement.  Is it really necessary to
>  > recompile gcc whenever you do anything else?
> 
> Why recompile? As long as you don't touch anything in the compiler's
> sources, "make" won't rebuild anything.
> 

Not true at all.  When there are configuration problems with the library, it
is often necessary to make distclean.  After that, you WILL recompile gcc,
and you WILL remake makeinfo, and you WILL remake whatever else is in all
those dependencies.  And you will do a good part of it before you get to do
the configure that you're really interested in, even though that's the
target you asked for.  This is really quite brain-damaged.

>  > PLEASE remove the dependencies
>  > on all-gcc from the library builds (and other places where it is not really
>  > needed).  This is an incredible nuisance when one is trying to debug a
>  > problem in the configure, and you have to do a make distclean.  If you want
>  > to have a grand general make all, that is fine.  But when people start using
>  > the fine-grained make targets, it really is better if they get only what
>  > they are asking for.
> 
> Perhaps this might be done sometime _after_ egcs-1.2.
> 
>  > 
>  > 
>  > I appreciate that you have taken the time to respond to my posting, but
>  > could you address the rest of the issues raised, which are our real
>  > concerns?
>  > 
> 
> No, these are beyong my scope. Somebody else from the list might
> put this on his list.
> 

Sigh, oh,well ...  You have definitely shed light on the source of the build
anomalies, and we do appreciate it.  I wish that I had more time to spend on
this, but I don't.  For now, we're going to have to just put egcs away and
try again later.

>  > What about the template instantiation problem?  Is the libstdc++ build
>  > supposed to work with -fno-implicit-templates?
>  > 
>  > What about the libio tfformat test?
>  > 
>  > My previous statement about losing a bunch of errors after installing
>  > libstdc++ is wrong.  I forgot to include the defines -DTEST_LIBIO
>  > -DTEST_EXACTNESS on the command line when I was testing.  When you do it
>  > right, all 1955 errors are still there, as expected.  However, the
>  > statements that there are no errors when compiling tfformat.c using the
>  > libio in glibc, or when compiliing it using the old gcc/g++/libstdc++ from
>  > the libc5 system are correct.  What about those errors?  Is this as
>  > expected, or do we still have a problem somewhere with the libio in
>  > libstdc++?
>  > 
>  > 

Regards,

Joe Parmelee
Wild Bear Systems
jparmele@wildbear.com