This is the mail archive of the gcc@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]

Re: Shared library annoyance with gcc-3_0-branch


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


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