Re: Development packages.
Stephen Frost <sfrost@snowman.net> writes:
> * Scott James Remnant (scott@netsplit.com) 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.
Reply to: