whither specs?

[Theodore Papadopoulo]

hjl@lucon.org said:
> I don't like -R for many reasons. One of them is
> # ls -d /usr/gcc* /usr/gcc-3.2  /usr/gcc-3.2-redhat-8  /usr/gcc-3.3
> I'd like to be able to remove the old ones and my C++ binaries are
> still ok. -R doesn't help me on that. 

Right -R does not help for this, but how does the current situation is
better with this respect. Currently, with gcc default installation:

- either you have root access and you pass the gcc library directory 
to ldconfig.

- either you let the work to the person that compiles the application,
and that boils down to do the -R flag thing at each time manually.
It can also be done by wrapping the call to the application into 
scripts setting first the LD_LIBRARY_PATH.

- either you leave the work to every user to specify the proper 
LD_LIBRARY_PATH.

- Finally, you compile things statically, and it is known to give the 
wrong behaviour in some cases.

Another solution for this last case is to install the compiler with 
only the static version of its libraries.

Of all those solution, only the static thingy allows you to suppress 
one of your gcc directory without trouble.


In all other cases, things will have to be done in case you remove 
the libgcc.so library. If I remember correctly (I can re-run the 
checks), even if you have specified a -R like flag at compilation 
time, then it is still possible to override it with a LD_LIBRARY_PATH 
when it is missing.

That being said, rth was OK for looking at a patch adding some -R 
like functionnality (just for gcc's own libraries) provided this was 
selected at configure time. I have it working for linux and solaris:
it basically works by generating the proper -Wlrpath directives
internally while processing the gcc specs for libraries. I got 
some comments at first versions of the patch... Then, at some point,
I posted a revised (partial) patch for cleaning up lib_spec handling
within gcc.c (most of the non-configury work was in that patch) and
got no answer. I should have probably ping'ed about that patch....

The patch is still available for review:
http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02176.html. But the 
compiler has somewhat changed in this area so that, if there is interest
in adding this functionnality, I can certainly update it.

Now, this was just a preparatory patch. The work needed to introduce 
the configury flag --with-runpath=XXXX is easy to do in principle 
but somewhat more hairy if I want it to behave correctly in all the 
situations (Non elf targets, HP, True64, ...).

Also, among the comments I had on the follow-up patch, was the fact that
rpath was the proper name instead of runpath (the latter being obsolete).
After searching for quite a while on the web, I finally found
http://stage.caldera.com/developer/gabi/latest/ch5.dynamic.html
which states exactly the opposite as far as I understand it. Is there 
a more up to date ressource ???


If there is interest for that feature, I will happily do the job on 
resurrecting the patches (Actually, I have it working, though I have 
not bootstrapped the compiler for a few weeks)... 

Presumably, I will introduce the feature first for the architectures I can test 
(gnu-linux and sparc-solaris), and then hopefully extending it to
other cases such as HP or AIX which have been mentionned previously
in this new thread, provided that I can get the necessary information.

That being said, I'm not clear on the fact that it will be possible to
implement the -R like flag for all the various combinations gcc supports.
Still, my belief is that something should be done when it is possible.

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------