Re: egcs testsuite & dejagnu : A special case?

[Craig Burley <burley at gnu dot org>]

>Ok, that is a nice design :).
>The only thing that is a bit unclear to me is how
>you will make it use the correct shared libraries
>at run time, of an executable compiled like that.

The exact same way that current uses of the just-built compiler do.  That
is, if it's a problem with my scheme, it's a problem with the current
test facilities and stuff.  All I'm suggesting is an encapsulation of
this need in the form of an interface exported by gcc.  If problems
like this arise, it's because external products that already use
built-not-installed versions of gcc have the same problems *now*, or
they solve it somehow, in which case the solutions should be removed
from those products to the implementations of these new interfaces.

I suppose another possibility exists, which we should head off by
documenting that the etc/ interfaces are not perfect and should
not generally be relied upon for any new uses that aren't just copies
of existing situations (e.g. dejagnu, make check, etc.).

>The same problem (will) occur when the -V option
>is used.  You should at least wait till H.J.
>added his patches to rename these shared libraries
>to something that includes the version of the
>compiler I think.

I can't imagine why the two are related.  If -V is used when
invoking built compilers already, then either that would work
fine with my approach (it just gets passed in anyway) or it's
a bug, right?

But getting me to wait isn't a problem, since I'm not planning
on doing this right away, and probably am not the best person
to do it.

>Apart from that, it would have a logical `feel'
>if it was possible to use the -V option for this,
>ie:
>
>gcc -V 2.7.2.3 ...
>gcc -V 2.8.1 ...
>gcc -V 2.91.45 ...
>gcc -V built ...
>
>Or something similar, where `gcc' would be just
>/usr/bin/gcc (some (old) egcs version).

That doesn't really help unless you mean to extend -V to support
an arbitrary pathname (does it do that already??) to a built
tree instead of an installed tree, in which case it'd know how
to do the -B/-L/whatever thing anyway.

There still would be a need, I think, for the ability to export
a single *command* that reliably invokes the built version of gcc,
g77, g++, etc.  Because not all external systems can take both a
command and an option that must be specified immediately after that
command as a substitution for the default `cc' or `gcc'.

        tq vm, (burley)