Re: Clearing/resetting g++/ld linker path for each -l

[Andy Buckley]

On 18 May, 15:11, Paul Pluzhnikov <ppluzhnikov-...@charter.net> wrote:
> Andy Buckley <a...@insectnation.org> writes:
> > I'd like to know if it's possible to clear the ld library search path
> > within a single linker call.
>
> I don't believe so. Also your question is about the linker; it has
> nothing to do with gcc/g++, and can't be answered without knowing
> which linker you are using. *Do* tell about your environment
> next time. Assuming Linux / GNU-ld for now.

Sorry - I don't normally forget! Yes, it's a Linux system and the
linker is GNU ld. That I'd like it to portably work across a variety
of linkers probably opens a whole new can of worms.

> > Specificlly, the problem is that I have
> > two libraries A and B, and there's a version of each in two include
> > paths, say /usr/lib and/usr/local/lib. So we've got /usr/lib/libA.so, /
> > usr/lib/libB.so, /usr/local/lib/libA.so and /usr/local/lib/libB.so.
>
> Ok, you've got a screwed-up system ...

Fortunately, it's not my system - it's the system of one of the users
of our software. But they want our software to build properly on their
system even though it's screwed up. It's academic software and
unfortunately some of the libraries that we depend on have to be on
the user's system in multiple versions, because yet more packages
can't use the newer versions yet. Yuck, but that's life, it seems.

> > Now I want to link against the version of library A from /usr/lib and
> > the version of B from /usr/local/lib. Unfortunately this command line
> > doesn't work:
>
> > g++ ... -L/usr/lib -lA -L/usr/local/lib -lB
>
> I think your only choice is to do this:
>
>   g++ ... /usr/lib/libA.so /usr/local/lib/libB.so

That's what I feared. Oh well, I guess I can do that given that I'm
already auto-detecting the library name and search path entry using a
few M4 macros in configure.ac.

> Even though this will do what you want at static link time, it may
> or may not do what you want at runtime (depending on whether SONAME
> is set in lib{A,B}.so).

Thanks for the tip - I guessed that LD_LIBRARY_PATH would have an
effect on runtime loading order - I've not encountered SONAME yet, so
will look into that. I'm also going to have similar problems making
sure that the right version of the headers gets picked up...

> > ? I'm using autotools and libtool if that's any help.
>
> Autotools will hinder rather than help you.

Quite possibly. I think we're stuck with it for now, though, at least
until SCons or similar is more mature and widespread. I noticed that
libtool already attempts to translate a lot of -L,-l switches into
absolute paths, so maybe it won't be too bad.

> > If there's no
> > way of doing that, is there any other technique which will avoid me
> > needing to rewrite a large chunk of our build system's m4 macros to
> > work out absolute paths for every library?
>
> The way to fix the problem is not to install conflicting versions
> into /usr/local/lib and /usr/lib. Install non-system versions of
> lib{A,B}.so into /usr/local/lib/lib{A,B}-v1/ and you would be
> able to control which version of which library you pick up:

Yes, I already suggested that. The issue is the extent to which I
should count their screwed up system as my build problem (e.g. to be
solved by me using absolute paths for linking) or their problem to be
solved by sorting out their system :)

> Note: if lib{A,B}.so have SONAME set (which arguably they should,
> since there are multiple incompatible versions), the picture grows
> even more complicated. The good news: if SONAME is set with proper
> version info, e.g. libA.so.1.2 for /usr/local/lib/libA.so and
> libA.so.1.1 for /usr/lib/libA.so (and similar SONAMEs for libB.so),
> then you can do what you want quite easily:
>
>   ln -s /usr/lib/libA.so .          &&
>   ln -s /usr/local/lib/libB.so .    &&
>   g++ ... -L. -lA -lB               &&
>   rm -f libA.so libB.so

Unfortunately this isn't a particularly neat thing to do with
autotools... oh well, it was worth a try. Thanks for your help.

Andy