Success...

[Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>]

	Hello,

	I've succesfully compiled and tested egcs-1.0 on my i586-pc-linux-gnulibc1
with the enable-shared flag set (my system is slackware based).

My only current grief is that I do not understand what is to be done with
shared libraries (specifically libstdc++.so.2.8.0). The FAQ states that we do
not want to add a -R flag for NFS access problems but does not give any
solution. OK, I can set my LD_LIBRARY_PATH variable but that does not seem
to be a proper solution when having many users. The only alternatives I can
see are:

	- Add the library directory to the cache used by the system (ldconfig like
      stuff). Or make links from /lib or /usr/lib to the proper libraries.

	- Impose a unique point of installation for the libraries
      (eg /usr/local/lib/gnu) and safely use a -R flag to that point.
	  I guess this is what are usually doing vendors such as Sun, HP, IBM,...

But in many cases this is not possible since root acces is needed to finish
the installation so that only two things can be done:

    - Have everyone to specify a LD_LIBRARY_PATH (I hate that solution).

    - Reintroduce the -R flag for $prefix/lib and know you cannot
      distribute compiled code.

	- Use an awful hack: an executable that would allow to directly change
      the corresponding flag in the executable (Really awful). This would
      certainly mean reserving some space in the binary file ??
      Sorry for even mentionning such a thing ;-) ...

Wouldn't it be possible to let the user decide which setup it prefers. This
would just mean allow for something like (I think the two options below
cover all the reasonnable situations):

	--enable-shared  (that does exactly what is done currently but with
    a message at the end of installation stating that the installer has
    to do something to catch this last problem (ldconfig or put a symbolic
    link at the proper location or whatever). 

	--enable-shared=Some_directory in which case the "-R Some_directory" will
    be added at the proper location in the spec file. And then emit a warning
    at configuration that this may lead to problems when exchanging binaries
    with other sites that may have a different configuration if static linking
    is not used.

Does this seems reasonnable ? Or am I missing stupidly another simple
solution.

	In any case, egcs is great !!!
	Thank's a lot for all the work it represents.

		Theo.

                === gcc Summary ===
 
# of expected passes            4883
# of expected failures          5
# of unsupported tests          7
/0/robotvis/papadop/gcc/egcs/egcs-1.0/gcc/xgcc version egcs-2.90.21 971202 (egcs-1.00 release)
 
   === g++ tests ===

XPASS: g++.jason/destruct3.C - (test for bogus messages, line 38)
XPASS: g++.mike/dyncast1.C  Execution test
XPASS: g++.mike/dyncast2.C  Execution test

=== g++ Summary ===

# of expected passes            3400
# of unexpected successes       3
# of expected failures          80
# of untested testcases         6
/0/robotvis/papadop/gcc/egcs/egcs-1.0/gcc/testsuite/../xgcc version egcs-2.90.21 971202 (egcs-1.00 release)

Test Run By papadop on Fri Dec  5 17:18:02 1997
Native configuration is i586-pc-linux-gnulibc1

=== g77 tests ===

FAIL: g77.f-torture/execute/dnrm2.f execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: g77.f-torture/execute/dnrm2.f execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
 
                === g77 Summary ===
 
# of expected passes            130
# of unexpected failures        2
/0/robotvis/papadop/gcc/egcs/egcs-1.0/gcc/g77 version egcs-2.90.21 971202 (egcs-1.00 release)



--------------------------------------------------------------------
Theodore Papadopoulo
Email:  papadop@sophia.inria.fr               Tel: (33) 93 65 76 01
--------------------------------------------------------------------