Re: problem setting up interlibrary dependencies
Steve Langasek <email@example.com> 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
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 firstname.lastname@example.org (NOT a valid e-mail address) for more info.