This is the mail archive of the gcc-bugs@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]
Other format: [Raw text]

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


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

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

For Solaris you have the additional options of

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

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

    5) Use $ORIGIN when linking.

    6) Use crle(1).

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.

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

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


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


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