[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ordering optional libraries
ordering optional libraries
Tue, 27 May 2003 00:18:58 +0200
advanced libraries can use weak symbols to dynamically change their
behaviour, depending on other libraries linked into the program.
However, that requires that the other libraries are linked before, so the
symbols are visible when the references in the library are resolved.
I use this in GPGME, which does not itself make use of threading, but needs
to protect some objects and global variables with locks in a threaded
environment. The goal is to support several thread packages, from no
threading to pthreads over pth. The old way to do it is to build several
versions of the same library (gpgme, gpgme_pthread, gpgme_pth), or to build
glue libraries (gpgme_lock_dummy, gpgme_lock_pthread, gpgme_lock_pth).
The first approach wastes disk space and requires the user to pick the right
library for the thread package he uses. The second approach requires the
user to pick the right library, and also inconveniences the simple case (no
threading) by requiring to link against a dummy library. Also, I don't
think that libtool understands the concept "one of these libraries must be
linked against", so I am not sure if the the second approach really would
work with libtool.
So, what I am using instead is using weak symbols. At least for platforms
that support them, they are an ideal solution from the users point of view:
He can do -lgpgme, -lpthread -lgpgme, -lpth -lgpgpme, any of these, and it
will always work correctly. However, the only requirement is important: The
thread package must preceed the GPGME library on the link command line.
libtool gets it wrong, because it doesn't know that GPGME has this
requirement, and will happily reorder the libs to have gpgme come before the
thread package (I don't know why, it might be alphabetical, or just bad
luck). This causes spurious bugs. It seems to be difficult to force the
right ordering without doing things like passing "-lpthread -lgpgme" (as one
argument), which surely is an ugly hack and requires the user to actively
match the thread package used against the command adding gpgme as a library.
So what I think would be a nice feature of libtool is the notion of optional
inter-library dependencies. Libraries that can be used by the library, but
it is not a bug if they are missing. Only that they are considered for
ordering when they are present.
Do you agree that this is a desirable feature, and if yes, is it hard to
implement? Would you accept a patch to do that (or if it is very simple,
just implement it?)
Please CC me, as I am not on the list.
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org address@hidden
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
|[Prev in Thread]
||[Next in Thread]|
- ordering optional libraries,
Marcus Brinkmann <=