an installation bug in either gcc, gld, or readline -- I don't know which

Andrew Koenig ark@research.att.com
Wed Dec 26 19:17:00 GMT 2001


Phil> On Wed, Dec 26, 2001 at 06:06:46PM -0500, Andrew Koenig wrote:

>> I encountered vaguely related problems in building gcc3.0 because
>> shared libraries are now the default, which means that you have to
>> do one of the following three things to get anything to work at all:

>> 1) Install stuff in /usr/lib
>> 2) Insist that every user set LD_LIBRARY_PATH when executing
>> a gcc executable
>> 3) Set LD_RUN_PATH during compilation

Phil> Pretty much.  "How to handle shared libraries" is one of those
Phil> extralinguistic things that hasn't really been standardized, not even to
Phil> the extent of best practicies or ad hoc industry standards.

Apparently.

Phil> For Solaris you have the additional options of

Phil>     4) Use '-Wl,-Rfoo' when linking, to embed 'foo' into the executable
Phil>        as a directory path to search at runtime.  This will work with both
Phil>        GNU and Sun ld (with sufficiently recent GNU versions).  E.g.,
Phil>        -Wl,-R/usr/gnu/lib

The thing is that someone has to supply that option.  Setting LD_RUN_PATH
is easier.

Phil>        There have been (n+1) discussions about making this the default
Phil>        behavior, or at least providing a driver switch to turn on such
Phil>        behavior (-embed-the-standard-runpath, etc).  So far no action
Phil>        has been taken.  Embedding runpaths into executables has its own
Phil>        disadvantages.

Yes -- for instance, it makes it hard to move the executables elsewhere.
But it's hard anywhere, because you don't know that the destination
has the required shared libraries.

Phil>     5) Use $ORIGIN when linking.

Phil>     6) Use crle(1).

Ah -- that's a command in Solaris 8 that isn't in Solaris 6.  As soon as
I convert the last of my Solaris 6 machines to 8, I'll consider that
as an alternative to LD_RUN_PATH.

Phil> Many of the above can be done on a system-wide basis, especially (6).


Phil> Ideally, readline and suchlike need to ask GCC "hey, what linker are you
Phil> using?" and GCC needs to answer in a portable way.  Right now this isn't
Phil> possible at either end.  Hmmm...
>> 
>> An alternative might be a --with-gnu-ld option as gcc has.

Phil> Actually, there is a portable bit of shell script to do this discovery
Phil> already.  It's part of the autoconf/automake/libtool family.  (Come to
Phil> think of it, it's part of libtool itself.)  But those aren't end-user
Phil> utilities; they're things that maintainers need to use in their build/install
Phil> procedures.

Phil> In this case, the readline people would have to adopt libtool rather than
Phil> calling their shobj-conf script.

Is that likely?

Meanwhile, I'm just patching shobj-conf, which seems to work.



More information about the Gcc-bugs mailing list