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

Re: problem setting up interlibrary dependencies



On Sat, Jul 12, 2003 at 11:05:54PM -0400, Aaron M. Ucko wrote:
> I'm running into difficulties getting vibrant6 [1] to comply with the
> new policy requiring full inter-library dependencies.  The source of
> the complication is that two of the libraries come in OpenGL and
> non-OpenGL variants, but certain intervening libraries are
> OpenGL-agnostic and therefore come in only one variant.

> Since OpenGL is a pretty hefty dependency, I'd like to avoid it if
> possible, and not have the intermediate libraries indirectly require
> it; on the other hand, the GL-enabled variant of the higher-level
> library (ncbicn3d) specifically needs the GL-enabled variant of the
> lower-level library (vibrant) in order to work properly.  I would also
> like for packages that request linkage against plain vibrant not to
> end up depending on the GL variant, even if built on systems with the
> GL variant installed.  (On the other hand, packages that specifically
> try to link against the GL variant should get it)

> I haven't quite been able to come up with a reasonable arrangement
> that satisfies all of these constraints.  The closest I've come up
> with so far falls apart the moment ldconfig runs:

>     BASELINE:
>     libvibrant-nogl.so.6.1.<date>: real file, soname libvibrant.so.6
>     libvibrant-nogl.so.6 -> libvibrant-nogl.so.6.1.<date>
>     [libvibrant-nogl.so -> libvibrant-nogl.so.6.1.<date>]
>     [libvibrant.so -> libvibrant-nogl.so]

>     WITHOUT libvibrant6-gl:
>     libvibrant.so.6 -> libvibrant-nogl.so.6

>     WITH libvibrant6-gl:
>     libvibrantOGL.so.6.1.<date>: real file, soname libvibrantOGL.so.6
>     libvibrantOGL.so.6 -> libvibrantOGL.so.6.1.<date>
>     [libvibrantOGL.so -> libvibrantOGL.so.6.1.<date>]
>     libvibrant.so.6 -> libvibrantOGL.so.6 (clobbered by ldconfig :-/)

> I could perhaps kludge around this by having libvibrant6-gl also
> contain a dummy library with a soname of libvibrant.so.6 that pulls in
> libvibrantOGL.so.6 and sorts after libvibrant-nogl.so.6.1.<date>, but
> that would be gross, and lead to odd-looking ldd output.

> Any suggestions?  Should I just punt and force everyone to use the
> OpenGL version?  (That would certainly be simplest, but I'd really
> prefer to avoid the dependency bloat if I can.)

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.

I see two possible strategies here.

1) Divide the library into two parts: one which provides the non-GL
functions, and one which provides *only* the GL functions.  This
provides a clear delineation of the functionality of each package; the
downside is that you (or upstream) would have to do a fair amount of
work to implement such a split, and you may have private functions that
have to be shared (rather, duplicated) between the two libs.

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.

-- 
Steve Langasek
postmodern programmer

Attachment: pgpxgLd9m2Tbr.pgp
Description: PGP signature


Reply to: