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:
pgp2m_alN7EHX.pgp
Description: PGP signature