On Mon, Jun 28, 2010 at 1:02 AM, Jeremy Lainé <jeremy.la...@m4x.org> wrote: > It looks as though there are two issues here: > > a/ My understanding is that upstream does a dlopen() on libdlm_lt.so in > order to be able to use libdlm_lt.so.2 or libdlm_lt.so.3 depending on the > system.
OK, but that will also pull in lidlm_lt.so.4, or libdlm_lt.so.5, or libdlm_lt.so.6... It would be wrong for libo2dlm to load libdlm_lt.so.4 before the developers even know what it is. The results would be unpredictable; potentially even dangerous. The whole point of "libfoo.so.N" is that N changes when and only when binary compatibility is broken. It also allows multiple "Ns" to co-exist on the same system. Using dlopen() on "libfoo.so" breaks both of those. libfoo.so is a development library. libfoo.so.N is a production (run-time) library. To have a production binary depend on libfoo.so is simply a bug, and I would like to help fix this bug upstream. I can think of three ways to do so: 1) Link against -ldlm_lt at compile time. This was rejected by the ocfs2 maintainers some time ago for introducing undesired dependencies. or 2) Have "configure" detect the version of libdlm_lt.so.N at compile time, and have libo2dlm use that. or 3) Modify libo2dlm/o2dlm.c to attempt to dlopen() libdlm_lt.so.3, then try libdlm_lt.so.2 if that fails. This is simplest, and maximizes portability of the binary, so it would be my suggestion. Joel, I volunteer to create and test a patch for any of these approaches, if you would find any of them acceptable. Just let me know. > I have added a patch for the next upload of ocfs2-tools which does just that: > > http://svn.debian.org/wsvn/collab-maint/deb-maint/ocfs2-tools/trunk/debian/patches/libo2dlm-dlopen-libdlm_lt.patch Thank you. Apparently, Suse is already applying exactly the same patch. But instead of every distribution fixing this bug for themselves, I would like to work together to get it fixed upstream. - Pat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
