[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: problem setting up interlibrary dependencies



Steve Langasek <vorlon@netexpress.net> writes:

> So to restate, you have two libraries which export similar ABIs, but not
> identical; the GL-enabled version of the library exports additional
> entry points which are only of use to a subset of callers.  You want to
> supply distinct .so links for each library, so that at build-time a
> program can clearly specify which variant it wishes to link against; and
> you don't want to drop the non-GL variant, because OpenGL is a hefty
> dependency for those who don't need it.

Right.  I would moreover like for the GL variant to supersede the
non-GL variant when both are installed, since that's what the
GL-neutral higher-level libraries will be linking against.

The way this worked up to now was that the only library dependencies
were on libc, with both variants residing in a single package that did
not depend on libGL(U); applications using the higher-level libraries
would have to link explicitly either against the non-GL variant or
against the GL variant and libGL(U).

> 1) Divide the library into two parts: one which provides the non-GL
> functions, and one which provides *only* the GL functions.  This

This would definitely be a pain, given that the two variants are built
from the same sources, just with different #defines.

> 2) Continue to ship complete versions of each library, tagging each with
> a unique soname and keeping their associated filenames entirely
> separate.  If someone wants the non-GL version, they link with
> -lvibrant; if they want the OpenGL-enabled version, they link with
> -lvibrant-gl.  Disadvantage: if you have a higher-level library that
> would use the non-GL version of the library, and an application that
> would use both this higher-level library and libvibrant-gl, you would
> have both libvibrant and libvibrant-gl loaded into memory, which
> probably won't work too well unless you implement symbol versioning as
> well.

Right, though I think I want the *opposite* of what symbol versioning
would give me: if the GL variant shows up at runtime in any fashion,
the process should not use any symbols from the non-GL variant, even
if it pulls it in indirectly.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger amu@monk.mit.edu (NOT a valid e-mail address) for more info.



Reply to: