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

[Joseph Parmelee <jparmele at wildbear dot com>]

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.

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

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.

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

I forgot to mention in my original post that after the link was corrected,
libg++ built and passed all its tests.


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


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?

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


Best regards,

Joe Parmelee
Wild Bear Systems
jparmele@wildbear.com