Steve Langasek <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
