Stephen Frost <[EMAIL PROTECTED]> writes: > * Scott James Remnant ([EMAIL PROTECTED]) wrote: >> > But shipping .la files in non-dev packages should still be a hanging >> > offense. >> >> Plugins using libltdl probably need them ... though not until some of >> the more exotic ports come to fruition. >> >> "Debian Solaris" anyone? :o) > > I'm not 100% sure but I actually thought that's what OpenLDAP used > (libltdl) and it works just fine w/o the stupid .la files.
Have you actually *used* libltdl yourself? For several reasons, it's often best (when dynamically loading modules) to load the .la file directly, and have libltdl do the magic of translating it to whatever.so for you. If you're writing your program to work on multiple platforms, this hides the issues you'll find: - You don't need to special case DSO extensions for every platform. Thus the package will work "out of the box" on every libltdl-supported platform. - This makes debugging and maintenance simpler and more reliable. - library conventions vary depending on the platform. Example: on Cygwin, DLLs are named cygfoo.dll, and live in /bin. The .la file would take care of this for me (I'd load /usr/lib/libfoo.la). You can do without the .la file, but IMHO it's too much hassle and causes more problems than it solves. If you want to use .so's directly, then just use libdl directly on Linux. For example, for Gimp-Print 5.0 (not yet released) I wrote a module loader that works in 3 modes: - libltdl [used when libdl is unavailable] - libdl [the default] - static [useful for debugging and static libs] Add a little configure magic to detect the best option, and you're all set. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]