[Top][All Lists]
[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