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