This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rewrite lib/g77.exp


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]