This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Shared library annoyance with gcc-3_0-branch
- To: Brad Lucier <lucier at math dot purdue dot edu>
- Subject: Re: Shared library annoyance with gcc-3_0-branch
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 16 Feb 2001 19:50:37 -0200
- Cc: jbuck at synopsys dot COM, gcc at gcc dot gnu dot org, Theodore dot Papadopoulo at sophia dot inria dot fr
- Organization: GCC Team, Red Hat
- References: <200102162119.f1GLJ7T27020@polya.math.purdue.edu>
On Feb 16, 2001, Brad Lucier <lucier@math.purdue.edu> wrote:
>> From aoliva@redhat.com Fri Feb 16 16:16:37 2001
>> On Feb 16, 2001, Brad Lucier <lucier@math.purdue.edu> wrote:
>>
>> > Is the following suggestion of Theodore Papadopoulo reasonable?
>>
>> It has been suggested before. I myself tried it once. At that time,
>> it was rejected.
>> Which, unfortunately, is not exactly the directory that would be
>> searched if GCC were to do it on itself. So, in a sense, the fact
>> that GCC doesn't do it by default is a good thing for my local
>> installations.
> I don't want it done by default, I want it to be a configure option.
Sounds good to me. The next exercise is to figure out what options
have to be passed on each architecture. Unfortunately, on some
architectures, it's *very* hard to do it.
The easiest scenario is just tacking an `-rpath/-R $(libdir)' flag
onto the linker specs, if the linker supports such a flag.
This will appear to work in general, but it will *override*
LD_RUN_PATH or equivalent, instead of adding to it. I.e., you'd want
something like `-rpath/-R ${LD_RUN_PATH+$LD_RUN_PATH:}$(libdir)'.
As long as -rpath/-R supports a colon-separated PATH, of course,
otherwise you'll want one separate switch for each component of
LD_RUN_PATH. And then, it may be that the user has issued
-Wl,-rpath/-R options in the command line. On platforms in which a
single -rpath/-R flag is supported, you must concatenate the one to be
implicitly added by GCC, but not LD_RUN_PATH, to the given PATH.
And then, there are platforms that don't support anything like
-rpath/-R, at all. Some use -L, in which case we're already ok. Some
use an environment variable such as LD_RUN_PATH (or overload
LD_LIBRARY_PATH), in which case you'd have to append to it.
See? It's not that simple.
The option I've been using in GCC up to 2.95.2 is to encode the full
pathname of the library in its SONAME. I've just hacked the
shared-library config files in libstdc++/config for all platforms I've
got, and it worked. I still have to figure out a way to do that with
libtool-created libraries, such as libstdc++-v3. So far, I have no
idea of how to approach the problem.
--
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