Aaron Stone wrote:
dlopen() is native on Linux and Solaris. If it's just Mac OS X that you're worried about, there's also dlcompat().http://www.opendarwin.org/projects/dlcompat/ To support Windows, HP-UX, and others, you are correct that libtool or glib will be appropriate. Here's a good HOWTO on the subject (mostly for dlopen, though) http://www.dwheeler.com/program-library/Program-Library-HOWTO/index.html AFAICT, nobody supports Mac OS X natively; dlcompat() seems widely used.
Ltdl claims it supports Mac OS X.
LTDL is seperate from libtool in most cases anyway, but it is very small and could even be patched into the source tree (two files, header and cfile). Do you want to keep it external or have it in the source?I'm still skeptical about becoming dependant upon glib, so I'd prefer to see libtool's ltdl used. They appear to be equivalently featureful. Additionally, because libtool makes generating shared libraries a breeze, it is likely that you'll need it for your libdbmail.so project anyways.
Understood. Most of the LTDL work is going to be like a list of all the functions and their type casts and a for statement to grab them all from the backend. Btw, I am designating the following way to change sql databases for dbmail in the conf file.
BACKEND="/usr/lib/dbmail/lib*sql.so.0" Dan Weber
Aaron Dan Weber <[EMAIL PROTECTED]> said:I am trying to decide which to use for dynamic library loading. The choices are glib's interface, or libtool's interface (ltdl). The standard dlopen() is not very portable (e.g. it doesn't exist on macosx). Both provide nice interfaces, someone give me some feedback.Dan Weber
signature.asc
Description: OpenPGP digital signature
