libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libdlloader


From: Gary V. Vaughan
Subject: Re: libdlloader
Date: Sun, 03 Oct 2004 15:04:24 +0100
User-agent: Mozilla Thunderbird 0.8 (Macintosh/20040913)

Hi Bob!

Bob Friesenhahn wrote:
Can someone please explain the theory of operation behind CVS libltdl's libdlloader

The loaders in libdlloader are lt_dlopened at runtime by dlpreopen.c. It will allow us to add a security measure of building a libltdl that can only dlpreopen libraries so that clients can abstract their modules
nicely, but not open their applications to arbitrary runtime code insertion.

It also means that the loaders are kept in a separate directory of files, which I hope might encourage contributions of additional loaders
(since it is plain what is required of a loader by example).

And finally, libtool 2.0's biggest new feature (for me) is that libraries can now dlopen modules, and be linked against preopenable libraries without interfering with one another. To be sure that this continues to work I wanted to use it in libltdl itself (so mdemo is testing that multiple module types can be independently loaded for the
correct client from a single library).

and why it is always built as an installed library (static/shared/DLL) regardless of whether or not libltdl is configured to be built as a convenience library?

libltdl still requires a .la file to be present for lt_dlopen to work.

 Installing a library when not requested seems like abnormal behavior.

libltdl needs to learn how to dlpreopen a preloaded library without an
installed .la file.  The code that does this is in the spaghetti at the
core of libltdl that I still don't understand very well.

libltdl/Makefile.am refers to Automake private variables.

I don't see any.  Which ones are private?

Why has the build of libltdl (a simple library) become so complicated?

Because libltdl is *not* a simple library, and it now allows us to do some very complicated things. (a) we can test them by eating our own dog food (b) the single ltdl.c file was becoming very hard to maintain,
so I am in the process of rewriting it in a modular style.

Cheers,
        Gary.
--
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]