libtool
[Top][All Lists]
Advanced

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

Re: Preloading without .la


From: Pierre Ossman
Subject: Re: Preloading without .la
Date: Mon, 09 Jan 2006 11:23:49 +0100
User-agent: Mozilla Thunderbird 1.0.7-2.1.fc4.nr (X11/20051011)

Ralf Wildenhues wrote:
Hi Pierre,


Hi Ralf,

* Pierre Ossman wrote on Tue, Jan 03, 2006 at 05:36:05PM CET:

I've been trying to use ltdl preloading without having any .la files, something that doesn't currently seem to be supported. I'm willing to implement a fix, provided a way out is presented.

The problem is that preloaded modules are given their static lib name, "foo.a". When loading the module, ltdl searches for "foo.so" and "foo.la". If "foo.la" exists, then "foo.a" will be found since that is the name in the "old_library" field of the la-file.


Comments welcome.


Yes, two comments.  First, read this thread as well:
http://lists.gnu.org/archive/html/bug-libtool/2005-11/msg00000.html

Second, think about systems with need_lib_prefix as well -- I believe
the fix to both issues should be very similar.  Documented here:
http://lists.gnu.org/archive/html/libtool/2005-10/msg00045.html


What a pain. And here I was hoping this was a trivial issue. :)

Third, if you could write a test for CVS libtool as well, that would
be *great*.


Sure. The big obstacle as I see it is defining how things should work.

Let's start with the interface. From the threads these calls should work with preloaded modules:

 - lt_dlopen("module.la")
 - lt_dlopenext("module")
 - lt_dlopenext("module.la")

The current, broken implementation allows:

 - lt_dlopen("module.a")

This isn't strictly correct, so it's debatable if this should be kept for backwards compatibility or not.

The question is if lt_dlopen("module.so") should work. I would lean towards no, since by specifying an exact module name you are knowingly trying to bypass some of ltdl's magic. To have this include bypassing preloading doesn't seem so far fetched.

Based on this I see changing the embedded name from 'module.a' to 'module.la' as the cleanest solution.

Now to throw this need_lib_prefix into the mix. Depending on where libtool prepends the prefix we will have to do different solutions (I haven't checked the code yet).

If the prefix is only present on the actual filename, meaning the application should load it using lt_dlopen('module.la') and have the la-file specify the correct name, then we should not special case preopened files. The rationale is the same as above. If the application does lt_dlopen('libmodule.so') then it is saying that it wants exactly that file, and not any magic lookup.

If the prefix gets embedded into the preopen name, then we should try and strip that off so that the embedded name is the same, independent of system.

If this solution sounds good then I'll start coding.


This approach has the disadvantage of breaking ABI on preloaded module
files -- not sure if we should care very much, but enough to make me
not want to put this in branch-1-5 probably.  Dunno yet, need to see
a working version and test it first.


The questions is how much regard one should have for breaking applications that use ltdl in an incorrect way. Well behaved programs should be respected though.


Your patch has a few issues.  First, `$shrext_cmds' is not necessarily a
literal, but may contain commands; `$std_shrext' may be used instead.
Second, the change breaks libltdl for both branch-1-5 and HEAD, but in
slightly different ways: in both you will be able to load the module
with the .so name, but not any more with the .la name.  Additionally,
branch-1-5 will not find the symbols any more.  You can test this with
libtool's mdemo test.


Ok. Let's scrap that patch for now and try to come up with desired behaviour first.

--
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com




reply via email to

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