success

success

[Italo Antonio]

just to let you know, i sucessfully compiled/installed gcc 2.95 on an
alphaev6-dec-osf4.0g
(thats not listed in the webpage)

bye

success

[Dave Carter]

Success building gcc-2.95.1.  Didn't see this on your build status page.

/usr/local/src/gcc-2.95.1> ./config.guess 
alpha-dec-osf4.0d

success

[Dave Carter]

Success building gcc-2.95.1.  Didn't see this on your build status page.

/usr/local/src/gcc-2.95.1> ./config.guess 
alpha-dec-osf4.0d

success

[Mike Williams]

alphaev6-dec-osf4.0f successful.

Mike Williams - Systems Manager. Mike@geharris.co.uk
These are my own opinions and should not be taken
as the opinion of GE Harris Energy Control Systems (UK) Ltd
or MPW Solutions Ltd.
Tel 01506 402 749 Fax 01506 416 818 

success

[Mike Williams]

alphaev6-dec-osf4.0f successful.

Mike Williams - Systems Manager. Mike@geharris.co.uk
These are my own opinions and should not be taken
as the opinion of GE Harris Energy Control Systems (UK) Ltd
or MPW Solutions Ltd.
Tel 01506 402 749 Fax 01506 416 818 

success

[Jens Racky]

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

pcrt1-2:~ # /usr4/egcs-19990517/config.guess
i586-pc-linux-gnu

Build on S.u.S.E. Linux 6.1, AMD-K6 CPU


Tschüß

Jens Racky

-- 
Dipl.-Ing. Jens Racky
Universitaet Kaiserslautern
Fachbereich Elektrotechnik
Lehrstuhl für Regelungstechnik und Signaltheorie
Postfach 3049             
Erwin-Schroedinger-Strasse
67653 Kaiserslautern
Telefon +49-[0]631-205-2829
Telefax +49-[0]631-205-4205
e-mail: Jens.Racky@e-technik.uni-kl.de
WWW: http://www.rhrk.uni-kl.de/~racky

success

[Jens Racky]

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

pcrt1-2:~ # /usr4/egcs-19990517/config.guess
i586-pc-linux-gnu

Build on S.u.S.E. Linux 6.1, AMD-K6 CPU


Tschüß

Jens Racky

-- 
Dipl.-Ing. Jens Racky
Universitaet Kaiserslautern
Fachbereich Elektrotechnik
Lehrstuhl für Regelungstechnik und Signaltheorie
Postfach 3049             
Erwin-Schroedinger-Strasse
67653 Kaiserslautern
Telefon +49-[0]631-205-2829
Telefax +49-[0]631-205-4205
e-mail: Jens.Racky@e-technik.uni-kl.de
WWW: http://www.rhrk.uni-kl.de/~racky

success

[chris]

I built egcs 1.1b

I have not tested it on my own programs yet but this will happen soon.
Thanks for makeing it.

Qubert

success

[Paul J. Tackley]

I successfully built and installed egcs on: i686-pc-linux-gnu

Paul Tackley

Success

[dcanazz]

i586-pc-linux-gnulibc1

Debian Linux 1.3.1, kernel 2.0.33
Istalled and working

daniele

Re: Success...

[Theodore Papadopoulo]

>>     - Have everyone to specify a LD_LIBRARY_PATH (I hate that solution).
>
>If you just set it in /etc/profile, it's not too horrible.

	Nope, not better. I do not want to have to modify it on many machines.
If I had to do such a thing the ldconfig solution would be better. For both
I need root access.

May be, I have not been precise enough. I'm in an environment where I cannot
change anything in root partitions (because I'm not a system manager).
However, we have a group of users and some common disk space in which I can
install egcs. The solution that I adopted last time (with gcc-2.7.2.1) was to
modify the spec file and this is transparent for the users as long as the
executables are not exchanged to other sites or as long as I do not remove
the libraries. If I had to ask all the users to change their LD_LIBRARY_PATH
variable, then I'm sure:

	- That most of them will not do it when I say it.
	- A lot of them will ask at random times later why it is not working.
	- Some other will make strange things with their LD_LIBRARY_PATH and
	  at some point will come to ask for help. And of course I want to minimize
	  my work. Actually, the common wisdom around here is to never set the
	  LD_LIBRARY_PATH variable because then you override the environment that
	  the installer has set up for you and this can fail miserably (I can at
	  least think of one or two example with various Motif1.2 librairies
	  originating from different vendors!!).

I do not think my situation is that un-common. The solution with the -R flag
in the spec file works and is not that bad. The only problem I had with
gcc-2.7.2.1 is that when static linking was selected the static versions
of the g++ libraries where not taken so that we had to specify the .a
libraries manually to link with them. Should this mis-feature is corrected
I do not see specifying the appropriate -R flag just for libstdc++.so as
a major problem since anyhow when we want to export binaries we always
compile them static in order to avoid any trouble with non-existing
libraries at the other sites.

	Now, that's only my 2p. Maybe I have not figured out yet what is the
big trouble in doing so. Anyhow my point was just to leave the installer
the choice without having to go and change the spec file by hand.

	Thank's a lot anyhow for your remark, I forgot that solution.

		Theo.

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

Success...

[Theodore Papadopoulo]

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