Re: rewrite lib/g77.exp

Re: rewrite lib/g77.exp

[Kaveh R. Ghazi]

 > From: Geoff Keating <geoffk@geoffk.org>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > >  > 2001-10-23  Geoffrey Keating  <geoffk@redhat.com>
 > >  > 
 > >  > 	    * lib/g77.exp: Rewrite based on lib/g++.exp.
 > > 
 > > Geoff,
 > > 
 > > Your patch seems to cause every test to fail on sparc-sun-solaris2.7.
 > > All tests yield this error:
 > > 
 > >  > collect2: ld returned 1 exit status
 > >  > compiler exited with status 1
 > >  > output is:
 > >  > /usr/ccs/bin/ld: illegal option -- -
 > >  > usage: ld [-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:] file(s)
 > >  > [...]
 > > 
 > > (I'm using native as/ld.)
 > > 
 > > When I revert your g77.exp patch I get only 9 failures.
 > 
 > Yes.
 > 
 > I'm sure the problem is with the second of these lines:
 > 
 > 	  if [file exists "${gccpath}/libf2c/.libs/libg2c.so"] {
 > 	      append flags "-Wl,--rpath-link,${rootme} "
 > 	      append ld_library_path ":${gccpath}/libf2c/.libs"
 > 	  }
 > 
 > which is GNU ld specific; it aims to ensure that the just-built
 > libgcc_s.so is linked against.  Can you propose a substitute for it
 > that works with both Solaris ld and GNU ld?


What's wrong with:

 > append ld_library_path ":${rootme}"

like in g++.exp?

		--Kaveh

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Oct 29, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
>> > From: Geoff Keating <geoffk@geoffk.org>

>> > I'm sure the problem is with the second of these lines:
>> > 
>> > 	  if [file exists "${gccpath}/libf2c/.libs/libg2c.so"] {
>> > 	      append flags "-Wl,--rpath-link,${rootme} "
>> > 	      append ld_library_path ":${gccpath}/libf2c/.libs"
>> > 	  }
>> > 
>> > which is GNU ld specific; it aims to ensure that the just-built
>> > libgcc_s.so is linked against.  Can you propose a substitute for it
>> > that works with both Solaris ld and GNU ld?
>> 
>> 
>> What's wrong with:
>> 
>> > append ld_library_path ":${rootme}"
>> 
>> like in g++.exp?

> It's not enough.  (You can see that g77.exp does in fact have that line.)

> It's possible this is a linker bug.

I recall a number of dynamic loaders will disregard LD_LIBRARY_PATH
when looking for dependencies of shared libraries.  This is one of the
reasons why I recommend using libtool for libgcc: then libtool will
know how to arrange for libg2c.la to find libgcc_s.so in the build
tree, and then, after they're installed, the installed copy of
libg2c.so will find libgcc_s.so in the install tree.

#include usual caveats about encoding search paths into shared
 libraries, and why they're good for many and bad for many others

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 26, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:
>> 
>> > Libstdc++ is not built on the host.  Test programs are.
>> 
>> Test programs are built for the target on the build machine, just like
>> libgcc, libstdc++, libobjc, libjava and libf2c.

> That would be pointless; we want to test the compiler that we just
> built, which may only run on the host.

I don't see how our current test-in-build-tree machinery could handle
this any differently.  Of course, we want to test the compiler we just
built, but if it won't run on the build machine, either we have to
install it and use some alternate testing machinery that uses an
installed compiler on the host, or we end up using for testing the
previously-installed build-x-target compiler used as part of the
host-x-target-on-build Canadian cross, which would be useless in terms
of testing the new compiler.

> Hmmm.  Do we really want to have a test procedure for testing in the
> build tree that's so different from how the user will likely use gcc?
> I mean, a libtool wrapper script is a lot of machinery.

If we want to test in the build tree, this is a must on at least one
platform, unless we get the test machinery to set up PATH correctly
such that Windows DLLs are found in the build tree.  Libtool would
only create such a wrapper script as a last resource, remember.
Besides, the current wrapper script is *very* simple.  Something like
setting LD_LIBRARY_PATH and running the program.  For Windows, this
gets to be a bit more complicated, since a shell script may not work
(think of Cygwin boxes without user-tools, i.e, no /bin/sh, or with
only the Cygwin DLL, or perhaps even without the DLL).

Of course, we're not going to run into this when testing in the build
tree, but libtool may eventually have to deal with this for
installable programs.  It's not of our (GCC) concern anyway.  Only the
simple wrapper scripts are.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Geoff Keating]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:
> 
> > Libstdc++ is not built on the host.  Test programs are.
> 
> Test programs are built for the target on the build machine, just like
> libgcc, libstdc++, libobjc, libjava and libf2c.

That would be pointless; we want to test the compiler that we just
built, which may only run on the host.

> >> > I don't believe that using libtool in the testsuite is the right
> >> > thing.  We don't require all user programs to use libtool, therefore
> >> > we shouldn't need it to test the compiler.
> >> 
> >> But we do require all user programs to figure out the appropriate
> >> flags to get their executables to find the shared libraries we
> >> install, if the system can't find them by default.  Also, when we're
> >> testing in the build tree, we don't have libraries in places they're
> >> searched for by default.  At least, we shouldn't assume as much.
> 
> > Does libtool handle running programs?  I thought it was only necessary
> > to build them.
> 
> In certain cases, yes, by creating wrapper scripts that set up the
> environment such that the program finds libraries in the build tree,
> instead of looking for them in the install tree.

Hmmm.  Do we really want to have a test procedure for testing in the
build tree that's so different from how the user will likely use gcc?
I mean, a libtool wrapper script is a lot of machinery.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> Libstdc++ is not built on the host.  Test programs are.

Test programs are built for the target on the build machine, just like
libgcc, libstdc++, libobjc, libjava and libf2c.

>> > I don't believe that using libtool in the testsuite is the right
>> > thing.  We don't require all user programs to use libtool, therefore
>> > we shouldn't need it to test the compiler.
>> 
>> But we do require all user programs to figure out the appropriate
>> flags to get their executables to find the shared libraries we
>> install, if the system can't find them by default.  Also, when we're
>> testing in the build tree, we don't have libraries in places they're
>> searched for by default.  At least, we shouldn't assume as much.

> Does libtool handle running programs?  I thought it was only necessary
> to build them.

In certain cases, yes, by creating wrapper scripts that set up the
environment such that the program finds libraries in the build tree,
instead of looking for them in the install tree.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 25, 2001, Zack Weinberg <zack@codesourcery.com> wrote:

> If we cannot make -R do the right thing on some platform, then we refuse
> to support shared libraries on that platform.  It is not our problem
> if a system has a broken linker, any more than it is our problem if its
> libc lacks C99 features.

Just like we currently create a __main() function that takes care of
dynamic initializers if the platform doesn't support this directly,
GCC could create a wrapper executable that set the environment and
fired the actual program in the rare cases in which there's no way to
get the linker to encode the correct search paths in the executable.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Geoff Keating]

> Cc: ghazi@caip.rutgers.edu, gcc-patches@gcc.gnu.org
> From: Alexandre Oliva <aoliva@redhat.com>
> Organization: GCC Team, Red Hat
> Date: 25 Nov 2001 04:38:17 -0200
> User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.7
> 
> On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:
> 
> > In addition, significant work would be required to make testing work
> > when the build system is not the host system.  libtool would probably
> > need to be configured twice, once for build-cross-host and once for
> > native on the host, and the native installed along with the
> > compiler/libraries.
> 
> A single build-cross-host would be enough, and, in fact, we already
> have this as part of libstdc++ and libf2c builds.  As soon as libgcc
> adopted libtool too, we'd have it for libgcc too.  We could use the
> libtool script of whatever language we were testing to run the
> language's testsuite.

Libstdc++ is not built on the host.  Test programs are.

> > I don't believe that using libtool in the testsuite is the right
> > thing.  We don't require all user programs to use libtool, therefore
> > we shouldn't need it to test the compiler.
> 
> But we do require all user programs to figure out the appropriate
> flags to get their executables to find the shared libraries we
> install, if the system can't find them by default.  Also, when we're
> testing in the build tree, we don't have libraries in places they're
> searched for by default.  At least, we shouldn't assume as much.

Does libtool handle running programs?  I thought it was only necessary
to build them.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: rewrite lib/g77.exp

[Zack Weinberg]

On Sun, Nov 25, 2001 at 04:27:09AM -0200, Alexandre Oliva wrote:
> On Nov 25, 2001, Zack Weinberg <zack@codesourcery.com> wrote:
> 
> > (b) make the driver and/or collect2 do the right thing in the first place.
> 
> > I will bet money that (b) is easier and more robust.
> 
> > Note that there's no reason to avoid the use of -rpath or equivalent
> > for the test suite.
> 
> Well, then go ahead and extract and maintain the `-rpath or
> equivalent' from the libtool configuration m4/sh into some form
> suitable for use in the testsuite.
[etc]

It doesn't go in the test suite, it goes in collect2 and/or the
gcc driver.  We define that gcc -R <whatever> does the right thing
on all platforms.  (I think this is effectively what Geoff just said
about collect3.)

If we cannot make -R do the right thing on some platform, then we refuse
to support shared libraries on that platform.  It is not our problem
if a system has a broken linker, any more than it is our problem if its
libc lacks C99 features.

zw

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> In addition, significant work would be required to make testing work
> when the build system is not the host system.  libtool would probably
> need to be configured twice, once for build-cross-host and once for
> native on the host, and the native installed along with the
> compiler/libraries.

A single build-cross-host would be enough, and, in fact, we already
have this as part of libstdc++ and libf2c builds.  As soon as libgcc
adopted libtool too, we'd have it for libgcc too.  We could use the
libtool script of whatever language we were testing to run the
language's testsuite.

> I don't believe that using libtool in the testsuite is the right
> thing.  We don't require all user programs to use libtool, therefore
> we shouldn't need it to test the compiler.

But we do require all user programs to figure out the appropriate
flags to get their executables to find the shared libraries we
install, if the system can't find them by default.  Also, when we're
testing in the build tree, we don't have libraries in places they're
searched for by default.  At least, we shouldn't assume as much.

> If we did need something like libtool for all user programs, we
> should build it into the compiler---and, to avoid having to think up
> a new name, why not name it 'collect3'?

I don't see a need for a separate collect executable.  If we go down
this path (which I think we should, and have indeed suggested it
before), we'd probably be better off just bundling this into collect2.
It's a matter of introducing a portable -rpath flag into the gcc
driver, that gets passed to collect2, and collect2 does whatever it
takes to get the linker to do the right thing in terms of encoding the
specified directories into the executable's rpath.

Regarding Zack's suggestion, on second thought, it's not that hard to
extract the information from libtool about how to do The Right Thing
(TM) in terms of passing rpath-like flags or environment variables to
the linker.  Duplicating the actual code is still a pity, but if
people don't want to use libtool because they'd rather duplicate all
the effort that has already gone into getting it to work on such a
large number of platforms, I won't oppose them too much.  I'd just
rather not do it myself.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 25, 2001, Zack Weinberg <zack@codesourcery.com> wrote:

> (b) make the driver and/or collect2 do the right thing in the first place.

> I will bet money that (b) is easier and more robust.

> Note that there's no reason to avoid the use of -rpath or equivalent
> for the test suite.

Well, then go ahead and extract and maintain the `-rpath or
equivalent' from the libtool configuration m4/sh into some form
suitable for use in the testsuite.  I'll point out again that some
linkers don't support anything like -rpath, and instead require either
(i) merging all -rpath directories into a single linker argument or
(ii) setting an environment variable at link time to the set of
directories to be used for searching or (iii) setting an environment
variable similarly, but at run time (I think Windows is the only such
brain-dead platform, and libtool doesn't handle this case correctly
yet, but it eventually will, by installing wrapper executables or
something alike).

I certainly don't want to make the effort of collecting this
information again and maintaining it in two different places.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Zack Weinberg]

On Sun, Nov 25, 2001 at 01:55:12AM -0200, Alexandre Oliva wrote:
> On Nov 17, 2001, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:
> 
> >> From: Alexandre Oliva <aoliva@redhat.com>
> 
> >> I recall a number of dynamic loaders will disregard LD_LIBRARY_PATH
> >> when looking for dependencies of shared libraries.  This is one of the
> >> reasons why I recommend using libtool for libgcc: then libtool will
> >> know how to arrange for libg2c.la to find libgcc_s.so in the build
> >> tree, and then, after they're installed, the installed copy of
> >> libg2c.so will find libgcc_s.so in the install tree.
> 
> > So can you help get the testsuite to use libtool so that this problem
> > is resolved?
> 
> It depends on getting approval to use libtool for libgcc, which has
> encountered some resistance in the past.

Yeah, you could say that.  Everything said in this thread only underlines
my opinion that libtool should not be used at all.

> Anyway, testsuites that currently depend on the compiler driver being
> able to compile and link in a single step have to be reworked such
> that they can do it in two steps.  Then, it's going to be possible to
> use libtool for the linking step, and get the benefit from it.  Still,
> we need libgcc_s to be a libtool archive in order for libtool to
> arrange for executables to know where to find libgcc_s at run time.

See, the choice is

(a) rewrite the entire test harness to shoehorn it into libtool's
    way of doing things,
(b) make the driver and/or collect2 do the right thing in the first place.

I will bet money that (b) is easier and more robust.

Note that there's no reason to avoid the use of -rpath or equivalent
for the test suite.  Those binaries are not going to be installed
anywhere, and they *should* look in the build tree for their shared
libraries.

zw

Re: rewrite lib/g77.exp

[Geoff Keating]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Nov 17, 2001, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:
> 
> >> From: Alexandre Oliva <aoliva@redhat.com>
> 
> >> I recall a number of dynamic loaders will disregard LD_LIBRARY_PATH
> >> when looking for dependencies of shared libraries.  This is one of the
> >> reasons why I recommend using libtool for libgcc: then libtool will
> >> know how to arrange for libg2c.la to find libgcc_s.so in the build
> >> tree, and then, after they're installed, the installed copy of
> >> libg2c.so will find libgcc_s.so in the install tree.
> 
> > So can you help get the testsuite to use libtool so that this problem
> > is resolved?
> 
> It depends on getting approval to use libtool for libgcc, which has
> encountered some resistance in the past.  Before that, using libtool
> for the testsuite won't get us at least this part of the benefit.
> 
> 
> Unfortunately, using libtool in the testsuite is going to be a
> significant undertaking.  The most significant reason is that libtool
> can't be used to convert a source file directly to an executable.  It
> needs separate compilation and linking steps, and the compilation step
> must not be done using libtool because compiling with libtool is
> useful to create libtool object files that are going into libtool
> archives.  They *can* be used for executables, but you don't get any
> benefit of using libtool for compilation of such object files, and it
> can significantly degrade performance.

In addition, significant work would be required to make testing work
when the build system is not the host system.  libtool would probably
need to be configured twice, once for build-cross-host and once for
native on the host, and the native installed along with the
compiler/libraries.

I don't believe that using libtool in the testsuite is the right
thing.  We don't require all user programs to use libtool, therefore
we shouldn't need it to test the compiler.  If we did need something
like libtool for all user programs, we should build it into the
compiler---and, to avoid having to think up a new name, why not name
it 'collect3'?

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 17, 2001, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:

>> From: Alexandre Oliva <aoliva@redhat.com>

>> I recall a number of dynamic loaders will disregard LD_LIBRARY_PATH
>> when looking for dependencies of shared libraries.  This is one of the
>> reasons why I recommend using libtool for libgcc: then libtool will
>> know how to arrange for libg2c.la to find libgcc_s.so in the build
>> tree, and then, after they're installed, the installed copy of
>> libg2c.so will find libgcc_s.so in the install tree.

> So can you help get the testsuite to use libtool so that this problem
> is resolved?

It depends on getting approval to use libtool for libgcc, which has
encountered some resistance in the past.  Before that, using libtool
for the testsuite won't get us at least this part of the benefit.


Unfortunately, using libtool in the testsuite is going to be a
significant undertaking.  The most significant reason is that libtool
can't be used to convert a source file directly to an executable.  It
needs separate compilation and linking steps, and the compilation step
must not be done using libtool because compiling with libtool is
useful to create libtool object files that are going into libtool
archives.  They *can* be used for executables, but you don't get any
benefit of using libtool for compilation of such object files, and it
can significantly degrade performance.

Anyway, testsuites that currently depend on the compiler driver being
able to compile and link in a single step have to be reworked such
that they can do it in two steps.  Then, it's going to be possible to
use libtool for the linking step, and get the benefit from it.  Still,
we need libgcc_s to be a libtool archive in order for libtool to
arrange for executables to know where to find libgcc_s at run time.

> You knew I was going to ask you, right? :-)

I must admit I didn't.  I never learn to keep my mouth shut :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 26, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:
>> 
>> > Libstdc++ is not built on the host.  Test programs are.
>> 
>> Test programs are built for the target on the build machine, just like
>> libgcc, libstdc++, libobjc, libjava and libf2c.

> That would be pointless; we want to test the compiler that we just
> built, which may only run on the host.

I don't see how our current test-in-build-tree machinery could handle
this any differently.  Of course, we want to test the compiler we just
built, but if it won't run on the build machine, either we have to
install it and use some alternate testing machinery that uses an
installed compiler on the host, or we end up using for testing the
previously-installed build-x-target compiler used as part of the
host-x-target-on-build Canadian cross, which would be useless in terms
of testing the new compiler.

> Hmmm.  Do we really want to have a test procedure for testing in the
> build tree that's so different from how the user will likely use gcc?
> I mean, a libtool wrapper script is a lot of machinery.

If we want to test in the build tree, this is a must on at least one
platform, unless we get the test machinery to set up PATH correctly
such that Windows DLLs are found in the build tree.  Libtool would
only create such a wrapper script as a last resource, remember.
Besides, the current wrapper script is *very* simple.  Something like
setting LD_LIBRARY_PATH and running the program.  For Windows, this
gets to be a bit more complicated, since a shell script may not work
(think of Cygwin boxes without user-tools, i.e, no /bin/sh, or with
only the Cygwin DLL, or perhaps even without the DLL).

Of course, we're not going to run into this when testing in the build
tree, but libtool may eventually have to deal with this for
installable programs.  It's not of our (GCC) concern anyway.  Only the
simple wrapper scripts are.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Geoff Keating]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:
> 
> > Libstdc++ is not built on the host.  Test programs are.
> 
> Test programs are built for the target on the build machine, just like
> libgcc, libstdc++, libobjc, libjava and libf2c.

That would be pointless; we want to test the compiler that we just
built, which may only run on the host.

> >> > I don't believe that using libtool in the testsuite is the right
> >> > thing.  We don't require all user programs to use libtool, therefore
> >> > we shouldn't need it to test the compiler.
> >> 
> >> But we do require all user programs to figure out the appropriate
> >> flags to get their executables to find the shared libraries we
> >> install, if the system can't find them by default.  Also, when we're
> >> testing in the build tree, we don't have libraries in places they're
> >> searched for by default.  At least, we shouldn't assume as much.
> 
> > Does libtool handle running programs?  I thought it was only necessary
> > to build them.
> 
> In certain cases, yes, by creating wrapper scripts that set up the
> environment such that the program finds libraries in the build tree,
> instead of looking for them in the install tree.

Hmmm.  Do we really want to have a test procedure for testing in the
build tree that's so different from how the user will likely use gcc?
I mean, a libtool wrapper script is a lot of machinery.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> Libstdc++ is not built on the host.  Test programs are.

Test programs are built for the target on the build machine, just like
libgcc, libstdc++, libobjc, libjava and libf2c.

>> > I don't believe that using libtool in the testsuite is the right
>> > thing.  We don't require all user programs to use libtool, therefore
>> > we shouldn't need it to test the compiler.
>> 
>> But we do require all user programs to figure out the appropriate
>> flags to get their executables to find the shared libraries we
>> install, if the system can't find them by default.  Also, when we're
>> testing in the build tree, we don't have libraries in places they're
>> searched for by default.  At least, we shouldn't assume as much.

> Does libtool handle running programs?  I thought it was only necessary
> to build them.

In certain cases, yes, by creating wrapper scripts that set up the
environment such that the program finds libraries in the build tree,
instead of looking for them in the install tree.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 25, 2001, Zack Weinberg <zack@codesourcery.com> wrote:

> If we cannot make -R do the right thing on some platform, then we refuse
> to support shared libraries on that platform.  It is not our problem
> if a system has a broken linker, any more than it is our problem if its
> libc lacks C99 features.

Just like we currently create a __main() function that takes care of
dynamic initializers if the platform doesn't support this directly,
GCC could create a wrapper executable that set the environment and
fired the actual program in the rare cases in which there's no way to
get the linker to encode the correct search paths in the executable.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Geoff Keating]

> Cc: ghazi@caip.rutgers.edu, gcc-patches@gcc.gnu.org
> From: Alexandre Oliva <aoliva@redhat.com>
> Organization: GCC Team, Red Hat
> Date: 25 Nov 2001 04:38:17 -0200
> User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.7
> 
> On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:
> 
> > In addition, significant work would be required to make testing work
> > when the build system is not the host system.  libtool would probably
> > need to be configured twice, once for build-cross-host and once for
> > native on the host, and the native installed along with the
> > compiler/libraries.
> 
> A single build-cross-host would be enough, and, in fact, we already
> have this as part of libstdc++ and libf2c builds.  As soon as libgcc
> adopted libtool too, we'd have it for libgcc too.  We could use the
> libtool script of whatever language we were testing to run the
> language's testsuite.

Libstdc++ is not built on the host.  Test programs are.

> > I don't believe that using libtool in the testsuite is the right
> > thing.  We don't require all user programs to use libtool, therefore
> > we shouldn't need it to test the compiler.
> 
> But we do require all user programs to figure out the appropriate
> flags to get their executables to find the shared libraries we
> install, if the system can't find them by default.  Also, when we're
> testing in the build tree, we don't have libraries in places they're
> searched for by default.  At least, we shouldn't assume as much.

Does libtool handle running programs?  I thought it was only necessary
to build them.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: rewrite lib/g77.exp

[Zack Weinberg]

On Sun, Nov 25, 2001 at 04:27:09AM -0200, Alexandre Oliva wrote:
> On Nov 25, 2001, Zack Weinberg <zack@codesourcery.com> wrote:
> 
> > (b) make the driver and/or collect2 do the right thing in the first place.
> 
> > I will bet money that (b) is easier and more robust.
> 
> > Note that there's no reason to avoid the use of -rpath or equivalent
> > for the test suite.
> 
> Well, then go ahead and extract and maintain the `-rpath or
> equivalent' from the libtool configuration m4/sh into some form
> suitable for use in the testsuite.
[etc]

It doesn't go in the test suite, it goes in collect2 and/or the
gcc driver.  We define that gcc -R <whatever> does the right thing
on all platforms.  (I think this is effectively what Geoff just said
about collect3.)

If we cannot make -R do the right thing on some platform, then we refuse
to support shared libraries on that platform.  It is not our problem
if a system has a broken linker, any more than it is our problem if its
libc lacks C99 features.

zw

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 25, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> In addition, significant work would be required to make testing work
> when the build system is not the host system.  libtool would probably
> need to be configured twice, once for build-cross-host and once for
> native on the host, and the native installed along with the
> compiler/libraries.

A single build-cross-host would be enough, and, in fact, we already
have this as part of libstdc++ and libf2c builds.  As soon as libgcc
adopted libtool too, we'd have it for libgcc too.  We could use the
libtool script of whatever language we were testing to run the
language's testsuite.

> I don't believe that using libtool in the testsuite is the right
> thing.  We don't require all user programs to use libtool, therefore
> we shouldn't need it to test the compiler.

But we do require all user programs to figure out the appropriate
flags to get their executables to find the shared libraries we
install, if the system can't find them by default.  Also, when we're
testing in the build tree, we don't have libraries in places they're
searched for by default.  At least, we shouldn't assume as much.

> If we did need something like libtool for all user programs, we
> should build it into the compiler---and, to avoid having to think up
> a new name, why not name it 'collect3'?

I don't see a need for a separate collect executable.  If we go down
this path (which I think we should, and have indeed suggested it
before), we'd probably be better off just bundling this into collect2.
It's a matter of introducing a portable -rpath flag into the gcc
driver, that gets passed to collect2, and collect2 does whatever it
takes to get the linker to do the right thing in terms of encoding the
specified directories into the executable's rpath.

Regarding Zack's suggestion, on second thought, it's not that hard to
extract the information from libtool about how to do The Right Thing
(TM) in terms of passing rpath-like flags or environment variables to
the linker.  Duplicating the actual code is still a pity, but if
people don't want to use libtool because they'd rather duplicate all
the effort that has already gone into getting it to work on such a
large number of platforms, I won't oppose them too much.  I'd just
rather not do it myself.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 25, 2001, Zack Weinberg <zack@codesourcery.com> wrote:

> (b) make the driver and/or collect2 do the right thing in the first place.

> I will bet money that (b) is easier and more robust.

> Note that there's no reason to avoid the use of -rpath or equivalent
> for the test suite.

Well, then go ahead and extract and maintain the `-rpath or
equivalent' from the libtool configuration m4/sh into some form
suitable for use in the testsuite.  I'll point out again that some
linkers don't support anything like -rpath, and instead require either
(i) merging all -rpath directories into a single linker argument or
(ii) setting an environment variable at link time to the set of
directories to be used for searching or (iii) setting an environment
variable similarly, but at run time (I think Windows is the only such
brain-dead platform, and libtool doesn't handle this case correctly
yet, but it eventually will, by installing wrapper executables or
something alike).

I certainly don't want to make the effort of collecting this
information again and maintaining it in two different places.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Zack Weinberg]

On Sun, Nov 25, 2001 at 01:55:12AM -0200, Alexandre Oliva wrote:
> On Nov 17, 2001, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:
> 
> >> From: Alexandre Oliva <aoliva@redhat.com>
> 
> >> I recall a number of dynamic loaders will disregard LD_LIBRARY_PATH
> >> when looking for dependencies of shared libraries.  This is one of the
> >> reasons why I recommend using libtool for libgcc: then libtool will
> >> know how to arrange for libg2c.la to find libgcc_s.so in the build
> >> tree, and then, after they're installed, the installed copy of
> >> libg2c.so will find libgcc_s.so in the install tree.
> 
> > So can you help get the testsuite to use libtool so that this problem
> > is resolved?
> 
> It depends on getting approval to use libtool for libgcc, which has
> encountered some resistance in the past.

Yeah, you could say that.  Everything said in this thread only underlines
my opinion that libtool should not be used at all.

> Anyway, testsuites that currently depend on the compiler driver being
> able to compile and link in a single step have to be reworked such
> that they can do it in two steps.  Then, it's going to be possible to
> use libtool for the linking step, and get the benefit from it.  Still,
> we need libgcc_s to be a libtool archive in order for libtool to
> arrange for executables to know where to find libgcc_s at run time.

See, the choice is

(a) rewrite the entire test harness to shoehorn it into libtool's
    way of doing things,
(b) make the driver and/or collect2 do the right thing in the first place.

I will bet money that (b) is easier and more robust.

Note that there's no reason to avoid the use of -rpath or equivalent
for the test suite.  Those binaries are not going to be installed
anywhere, and they *should* look in the build tree for their shared
libraries.

zw

Re: rewrite lib/g77.exp

[Geoff Keating]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Nov 17, 2001, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:
> 
> >> From: Alexandre Oliva <aoliva@redhat.com>
> 
> >> I recall a number of dynamic loaders will disregard LD_LIBRARY_PATH
> >> when looking for dependencies of shared libraries.  This is one of the
> >> reasons why I recommend using libtool for libgcc: then libtool will
> >> know how to arrange for libg2c.la to find libgcc_s.so in the build
> >> tree, and then, after they're installed, the installed copy of
> >> libg2c.so will find libgcc_s.so in the install tree.
> 
> > So can you help get the testsuite to use libtool so that this problem
> > is resolved?
> 
> It depends on getting approval to use libtool for libgcc, which has
> encountered some resistance in the past.  Before that, using libtool
> for the testsuite won't get us at least this part of the benefit.
> 
> 
> Unfortunately, using libtool in the testsuite is going to be a
> significant undertaking.  The most significant reason is that libtool
> can't be used to convert a source file directly to an executable.  It
> needs separate compilation and linking steps, and the compilation step
> must not be done using libtool because compiling with libtool is
> useful to create libtool object files that are going into libtool
> archives.  They *can* be used for executables, but you don't get any
> benefit of using libtool for compilation of such object files, and it
> can significantly degrade performance.

In addition, significant work would be required to make testing work
when the build system is not the host system.  libtool would probably
need to be configured twice, once for build-cross-host and once for
native on the host, and the native installed along with the
compiler/libraries.

I don't believe that using libtool in the testsuite is the right
thing.  We don't require all user programs to use libtool, therefore
we shouldn't need it to test the compiler.  If we did need something
like libtool for all user programs, we should build it into the
compiler---and, to avoid having to think up a new name, why not name
it 'collect3'?

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: rewrite lib/g77.exp

[Alexandre Oliva]

On Nov 17, 2001, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:

>> From: Alexandre Oliva <aoliva@redhat.com>

>> I recall a number of dynamic loaders will disregard LD_LIBRARY_PATH
>> when looking for dependencies of shared libraries.  This is one of the
>> reasons why I recommend using libtool for libgcc: then libtool will
>> know how to arrange for libg2c.la to find libgcc_s.so in the build
>> tree, and then, after they're installed, the installed copy of
>> libg2c.so will find libgcc_s.so in the install tree.

> So can you help get the testsuite to use libtool so that this problem
> is resolved?

It depends on getting approval to use libtool for libgcc, which has
encountered some resistance in the past.  Before that, using libtool
for the testsuite won't get us at least this part of the benefit.


Unfortunately, using libtool in the testsuite is going to be a
significant undertaking.  The most significant reason is that libtool
can't be used to convert a source file directly to an executable.  It
needs separate compilation and linking steps, and the compilation step
must not be done using libtool because compiling with libtool is
useful to create libtool object files that are going into libtool
archives.  They *can* be used for executables, but you don't get any
benefit of using libtool for compilation of such object files, and it
can significantly degrade performance.

Anyway, testsuites that currently depend on the compiler driver being
able to compile and link in a single step have to be reworked such
that they can do it in two steps.  Then, it's going to be possible to
use libtool for the linking step, and get the benefit from it.  Still,
we need libgcc_s to be a libtool archive in order for libtool to
arrange for executables to know where to find libgcc_s at run time.

> You knew I was going to ask you, right? :-)

I must admit I didn't.  I never learn to keep my mouth shut :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: rewrite lib/g77.exp

[Kaveh R. Ghazi]

 > From: Alexandre Oliva <aoliva@redhat.com>
 > 
 > On Oct 29, 2001, Geoff Keating <geoffk@geoffk.org> wrote:
 > 
 > > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > >> > From: Geoff Keating <geoffk@geoffk.org>
 > 
 > >> > I'm sure the problem is with the second of these lines:
 > >> > 
 > >> > 	  if [file exists "${gccpath}/libf2c/.libs/libg2c.so"] {
 > >> > 	      append flags "-Wl,--rpath-link,${rootme} "
 > >> > 	      append ld_library_path ":${gccpath}/libf2c/.libs"
 > >> > 	  }
 > >> > 
 > >> > which is GNU ld specific; it aims to ensure that the just-built
 > >> > libgcc_s.so is linked against.  Can you propose a substitute for it
 > >> > that works with both Solaris ld and GNU ld?
 > >> 
 > >> 
 > >> What's wrong with:
 > >> 
 > >> > append ld_library_path ":${rootme}"
 > >> 
 > >> like in g++.exp?
 > 
 > > It's not enough.  (You can see that g77.exp does in fact have that line.)
 > 
 > > It's possible this is a linker bug.
 > 
 > I recall a number of dynamic loaders will disregard LD_LIBRARY_PATH
 > when looking for dependencies of shared libraries.  This is one of the
 > reasons why I recommend using libtool for libgcc: then libtool will
 > know how to arrange for libg2c.la to find libgcc_s.so in the build
 > tree, and then, after they're installed, the installed copy of
 > libg2c.so will find libgcc_s.so in the install tree.

So can you help get the testsuite to use libtool so that this problem
is resolved?  You knew I was going to ask you, right? :-)

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: rewrite lib/g77.exp

[Franz Sirl]

On Sunday 28 October 2001 19:09, Geoff Keating wrote:
> > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> > Date: Sun, 28 Oct 2001 18:43:43 +0100
> >
> > On Sunday 28 October 2001 18:36, Geoff Keating wrote:
> > > I'm sure the problem is with the second of these lines:
> > >
> > > 	  if [file exists "${gccpath}/libf2c/.libs/libg2c.so"] {
> > > 	      append flags "-Wl,--rpath-link,${rootme} "
> > > 	      append ld_library_path ":${gccpath}/libf2c/.libs"
> > > 	  }
> > >
> > > which is GNU ld specific; it aims to ensure that the just-built
> > > libgcc_s.so is linked against.  Can you propose a substitute for it
> > > that works with both Solaris ld and GNU ld?
> > >
> > > [Note that just deleting it may appear to fix the problem, but is more
> > > likely to be hiding it if you have libgcc_s.so installed somewhere.]
> >
> > Uhm, don't we need the shared-libgcc handling in g77spec.c first like we
> > have in g++spec.c and gccspec.c? I think fixing this will eliminate the
> > testsuite problem with the shared libgcc.
>
> I don't think the gccspec.c code has any effect when compiling normal
> C code, does it?

Well, it does for ObjC (which is the ugliest one cause there is no separate 
driver for it). I believe the rule is that any driver linking in special libs 
like -lobjc, -lstdc++ or -lg2c needs to have the shared-libgcc handling in 
its land_specific_driver().

Franz.

Re: rewrite lib/g77.exp

[Geoff Keating]

> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Sun, 28 Oct 2001 18:43:43 +0100

> On Sunday 28 October 2001 18:36, Geoff Keating wrote:
> > I'm sure the problem is with the second of these lines:
> >
> > 	  if [file exists "${gccpath}/libf2c/.libs/libg2c.so"] {
> > 	      append flags "-Wl,--rpath-link,${rootme} "
> > 	      append ld_library_path ":${gccpath}/libf2c/.libs"
> > 	  }
> >
> > which is GNU ld specific; it aims to ensure that the just-built
> > libgcc_s.so is linked against.  Can you propose a substitute for it
> > that works with both Solaris ld and GNU ld?
> >
> > [Note that just deleting it may appear to fix the problem, but is more
> > likely to be hiding it if you have libgcc_s.so installed somewhere.]
> 
> Uhm, don't we need the shared-libgcc handling in g77spec.c first like we have 
> in g++spec.c and gccspec.c? I think fixing this will eliminate the testsuite 
> problem with the shared libgcc.

I don't think the gccspec.c code has any effect when compiling normal
C code, does it?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: rewrite lib/g77.exp

[Franz Sirl]

On Sunday 28 October 2001 18:36, Geoff Keating wrote:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> >  > 2001-10-23  Geoffrey Keating  <geoffk@redhat.com>
> >  >
> >  > 	    * lib/g77.exp: Rewrite based on lib/g++.exp.
> >
> > Geoff,
> >
> > Your patch seems to cause every test to fail on sparc-sun-solaris2.7.
> >
> > All tests yield this error:
> >  > collect2: ld returned 1 exit status
> >  > compiler exited with status 1
> >  > output is:
> >  > /usr/ccs/bin/ld: illegal option -- -
> >  > usage: ld [-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:]
> >  > file(s) [...]
> >
> > (I'm using native as/ld.)
> >
> > When I revert your g77.exp patch I get only 9 failures.
>
> Yes.
>
> I'm sure the problem is with the second of these lines:
>
> 	  if [file exists "${gccpath}/libf2c/.libs/libg2c.so"] {
> 	      append flags "-Wl,--rpath-link,${rootme} "
> 	      append ld_library_path ":${gccpath}/libf2c/.libs"
> 	  }
>
> which is GNU ld specific; it aims to ensure that the just-built
> libgcc_s.so is linked against.  Can you propose a substitute for it
> that works with both Solaris ld and GNU ld?
>
> [Note that just deleting it may appear to fix the problem, but is more
> likely to be hiding it if you have libgcc_s.so installed somewhere.]

Uhm, don't we need the shared-libgcc handling in g77spec.c first like we have 
in g++spec.c and gccspec.c? I think fixing this will eliminate the testsuite 
problem with the shared libgcc.

Franz.

Re: rewrite lib/g77.exp

[Geoff Keating]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

>  > 2001-10-23  Geoffrey Keating  <geoffk@redhat.com>
>  > 
>  > 	    * lib/g77.exp: Rewrite based on lib/g++.exp.
> 
> Geoff,
> 
> Your patch seems to cause every test to fail on sparc-sun-solaris2.7.
> All tests yield this error:
> 
>  > collect2: ld returned 1 exit status
>  > compiler exited with status 1
>  > output is:
>  > /usr/ccs/bin/ld: illegal option -- -
>  > usage: ld [-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:] file(s)
>  > [...]
> 
> (I'm using native as/ld.)
> 
> When I revert your g77.exp patch I get only 9 failures.

Yes.

I'm sure the problem is with the second of these lines:

	  if [file exists "${gccpath}/libf2c/.libs/libg2c.so"] {
	      append flags "-Wl,--rpath-link,${rootme} "
	      append ld_library_path ":${gccpath}/libf2c/.libs"
	  }

which is GNU ld specific; it aims to ensure that the just-built
libgcc_s.so is linked against.  Can you propose a substitute for it
that works with both Solaris ld and GNU ld?

[Note that just deleting it may appear to fix the problem, but is more
likely to be hiding it if you have libgcc_s.so installed somewhere.]

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: rewrite lib/g77.exp

[Kaveh R. Ghazi]

 > 2001-10-23  Geoffrey Keating  <geoffk@redhat.com>
 > 
 > 	    * lib/g77.exp: Rewrite based on lib/g++.exp.

Geoff,

Your patch seems to cause every test to fail on sparc-sun-solaris2.7.
All tests yield this error:

 > collect2: ld returned 1 exit status
 > compiler exited with status 1
 > output is:
 > /usr/ccs/bin/ld: illegal option -- -
 > usage: ld [-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:] file(s)
 > [...]

(I'm using native as/ld.)

When I revert your g77.exp patch I get only 9 failures.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: rewrite lib/g77.exp

[Geoff Keating]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> On Tue, 23 Oct 2001, Geoffrey Keating wrote:
> 
> > So, I rewrote g77.exp
> 
> > # This file was written by Rob Savoye (rob@cygnus.com)
> > # Many modifications by Jeffrey Wheat (cassidy@cygnus.com)
> > # With modifications by Mike Stump <mrs@cygnus.com>.
> 
> Are these comments still accurate?

They're as accurate as the similar comments in the file g++.exp, which
the new version is based on.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: rewrite lib/g77.exp

[Joseph S. Myers]

On Tue, 23 Oct 2001, Geoffrey Keating wrote:

> So, I rewrote g77.exp

> # This file was written by Rob Savoye (rob@cygnus.com)
> # Many modifications by Jeffrey Wheat (cassidy@cygnus.com)
> # With modifications by Mike Stump <mrs@cygnus.com>.

Are these comments still accurate?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

rewrite lib/g77.exp

[Geoffrey Keating]

x86-linux native test runs were experiencing a number of failures on a
machine where gcc 3.0 was not installed, because libgcc_s.so was
not being found.  (Of course, this is even worse when gcc 3.0 _was_
installed, because it meant that the wrong libgcc_s.so was being
tested.)

I also encountered other problems.  So, I rewrote g77.exp to make it
more like g++.exp, and fixed this bug on the way.

I've just included the new g77.exp below directly because the diff is
not very helpful.

Tested on x86-linux, both with 'make check-g77' in the gcc/ directory,
and 'make check-gcc' in the toplevel directory; I'll also check
powerpc-eabisim before committing.

-- 
Geoff Keating <geoffk@redhat.com>

2001-10-23  Geoffrey Keating  <geoffk@redhat.com>

	* lib/g77.exp: Rewrite based on lib/g++.exp.

===File ~/co/egcs-mainline/gcc/gcc/testsuite/lib/g77.exp====
# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 2000, 2001 Free Software Foundation, Inc.

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

# This file was written by Rob Savoye (rob@cygnus.com)
# Many modifications by Jeffrey Wheat (cassidy@cygnus.com)
# With modifications by Mike Stump <mrs@cygnus.com>.

#
# g77 support library routines
#
load_lib prune.exp
load_lib gcc-defs.exp

#
# G77_UNDER_TEST is the compiler under test.
#


set gpp_compile_options ""


#
# g77_version -- extract and print the version number of the compiler
#

proc g77_version { } {
    global G77_UNDER_TEST
    
    g77_init

    # ignore any arguments after the command
    set compiler [lindex $G77_UNDER_TEST 0]
    
    # verify that the compiler exists
    if { [is_remote host] || [which $compiler] != 0 } then {
	set tmp [remote_exec host "$compiler -v"]
	set status [lindex $tmp 0];
	set output [lindex $tmp 1];
	regexp "version.*$" $output version
	if { $status == 0 && [info exists version] } then {
	    if [is_remote host] {
		clone_output "$compiler $version\n"
	    } else {
		clone_output "[which $compiler] $version\n"
	    }
	} else {
	    clone_output "Couldn't determine version of [which $compiler]\n"
	}
    } else {
	# compiler does not exist (this should have already been detected)
	warning "$compiler does not exist"
    }
}

#
# g77_link_flags -- provide new version of g77_link_flags
# (originally from libgloss.exp) which knows about the gcc tree structure
#

proc g77_link_flags { paths } {
    global rootme
    global srcdir
    global ld_library_path

    set gccpath ${paths}
    set libio_dir ""
    set flags ""
    set ld_library_path "."

    if { $gccpath != "" } {
      if [file exists "${gccpath}/libf2c/.libs/libg2c.a"] {
          append flags "-L${gccpath}/libf2c/.libs "
	  if [file exists "${gccpath}/libf2c/.libs/libg2c.so"] {
	      append flags "-Wl,--rpath-link,${rootme} "
	      append ld_library_path ":${gccpath}/libf2c/.libs"
	  }
      }
      if [file exists "${gccpath}/libf2c/libfrtbegin.a"] {
          append flags "-L${gccpath}/libf2c "
      }
      if [file exists "${gccpath}/libiberty/libiberty.a"] {
          append flags "-L${gccpath}/libiberty "
      }
      append ld_library_path ":${rootme}"
    }
    return "$flags"
}

#
# g77_init -- called at the start of each subdir of tests
#

proc g77_init { args } {
    global subdir
    global gpp_initialized
    global base_dir
    global tmpdir
    global libdir
    global gluefile wrap_flags;
    global objdir srcdir
    global ALWAYS_G77FLAGS
    global TOOL_EXECUTABLE TOOL_OPTIONS
    global G77_UNDER_TEST
    global TESTING_IN_BUILD_TREE

    if ![info exists G77_UNDER_TEST] then {
	if [info exists TOOL_EXECUTABLE] {
	    set G77_UNDER_TEST $TOOL_EXECUTABLE;
	} else {
	    if { [is_remote host] || ! [info exists TESTING_IN_BUILD_TREE] } {
		set G77_UNDER_TEST [transform g77]
	    } else {
		set G77_UNDER_TEST [findfile $base_dir/../g77 "$base_dir/../g77 -B$base_dir/../" [findfile $base_dir/g77 "$base_dir/g77 -B$base_dir/" [transform g77]]]
	    }
	}
    }

    if ![is_remote host] {
	if { [which $G77_UNDER_TEST] == 0 } then {
	    perror "G77_UNDER_TEST ($G77_UNDER_TEST) does not exist"
	    exit 1
	}
    }
    if ![info exists tmpdir] {
	set tmpdir "/tmp"
    }

    if [info exists gluefile] {
	unset gluefile
    }

    if { [target_info needs_status_wrapper] != "" } {
	set gluefile ${tmpdir}/testglue.o;
	set result [build_wrapper $gluefile];
	if { $result != "" } {
	    set gluefile [lindex $result 0];
	    set wrap_flags [lindex $result 1];
	} else {
	    unset gluefile
	}
    }

    set ALWAYS_G77FLAGS ""

    if ![is_remote host] {
	if [info exists TOOL_OPTIONS] {
	    lappend ALWAYS_G77FLAGS "ldflags=[g77_link_flags [get_multilibs ${TOOL_OPTIONS}] ]";
	} else {
	    lappend ALWAYS_G77FLAGS "ldflags=[g77_link_flags [get_multilibs] ]";
	}
    }

    if [info exists TOOL_OPTIONS] {
	lappend ALWAYS_G77FLAGS "additional_flags=$TOOL_OPTIONS";
    }

    verbose -log "ALWAYS_G77FLAGS set to $ALWAYS_G77FLAGS"

    verbose "g77 is initialized" 3
}

#
# g77_target_compile -- compile a source file
#

proc g77_target_compile { source dest type options } {
    global tmpdir;
    global gluefile wrap_flags
    global ALWAYS_G77FLAGS;
    global G77_UNDER_TEST;

    if { [target_info needs_status_wrapper] != "" && [info exists gluefile] } {
	lappend options "libs=${gluefile}"
	lappend options "ldflags=${wrap_flags}"
    }

    lappend options "compiler=$G77_UNDER_TEST";

    set options [concat "$ALWAYS_G77FLAGS" $options];

    return [target_compile $source $dest $type $options]
}

#
# g77_set_ld_library_path --
# On IRIX 6, we have to set variables akin to LD_LIBRARY_PATH, but
# called LD_LIBRARYN32_PATH (for the N32 ABI) and LD_LIBRARY64_PATH
# (for the 64-bit ABI).  The right way to do this would be to modify
# unix.exp -- but that's not an option since it's part of DejaGNU
# proper, so we do it here, by trickery.  We really only need to do 
# this on IRIX, but it shouldn't hurt to do it anywhere else.
#

proc ${tool}_set_ld_library_path { name element op } {
  setenv LD_LIBRARYN32_PATH [getenv LD_LIBRARY_PATH]
  setenv LD_LIBRARY64_PATH [getenv LD_LIBRARY_PATH]
}

trace variable env(LD_LIBRARY_PATH) w ${tool}_set_ld_library_path
============================================================