[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: Wed, 01 Mar 2006 12:26:45 +0100
User-agent: Thunderbird 1.5 (X11/20060119)

Ralf Wildenhues wrote:
[ Let's move this to libtool-patches
  Note also the list server may not come back up for a few days. ]

Major breakage?

Hi Pierre,

Sorry for the delay.

No problem.

* Pierre Ossman wrote on Fri, Jan 27, 2006 at 05:30:22PM CET:
I've put together a suggestion (against 1.5 branch, but the difference shouldn't be that big compared to HEAD) for this.

Many thanks for your effort!  I'm not convinced yet that this is the way
to go, on the contrary, I have real doubts, but at least this is a start.

Fair enough. Just as long as we're moving forward in some sense since this is an actual problem for me.

What it does is strip ${libext} from the name and, if we're on a $need_lib_prefix system, applies a command that should reverse the effect of $libname_spec. It then appends the '.la' extension.

OK.  But the '.la' extension should be necessary for preloading only.

The effect is that preloading and "normal" loading will work for any application that uses the platform independent ways of loading:


Any programs that uses lt_dlopen("module.a") will break with this patch. But I would consider such a call unsupported since they've been mucking about in libtool internals to figure out that name.

My tests show that also lt_dlopen("") may fail on some systems.

Can you point me to what test you did to break this?

The is another breakage caused by the fact that libtool special cases the 'lib' prefix. dlpreopening a module called libfoo on a $need_lib_prefix system with a prefix of 'lib' will not work. The reason is that the above magic cannot tell the difference between 'libfoo' and 'foo' (which will be transformed to 'libfoo') on such a system.

I'm still afraid this will cause user breakage.  You can neither expect
the user to use the prefix nor to omit it.  It's much too useful to be
able to dlopen "regular libraries", this feature is used often.

Hmm... I don't really know how to solve this. The information that the prefix was added automatically will not always be available (we might be linking in a lib without a .la file).

It might be possible to be more clever by modifying the loading routines in libltdl. But I wanted to explore the option of just changing the build environment first.

What we could do is have libprefix actually be a prefix (not a command which can do all kinds of funky stuff). That prefix could then be built into libltdl so that if will try adding it when looking for the module.

Please review and comment. If it looks good I'll make a patch for HEAD and try to do some test cases.

The naming is a bit inconsistent: we use `*_cmds' for `~'-separated
lists of commands -- yes, shrext_cmds is a bad counter example, and
should be fixed, too.  It should either be libname_rev, since it's
not a command at all, or ltmain should be able to cope with (multiple)
commands in there.  (This is documented in libtool.texi, too.)

Have you tested it?  I tested something like the patch below (after the
forward port of your patch).  There are several ugly details to be aware
of: Inside the backquotes in libname_rev, you may not use double quotes.
This is because the config.status escaping would then lead to
which is not portable.  Also, to use $Xsed, you should add an X,
and an `-e'.  ;-)

Fluff ;)

The code is still a bit hackish until we have a principle that's correct.

The patch below is missing at least documentation of `libname_rev' in
libtool.texi, and some decent tests, beside the cheap one.

For me this breaks mdemo-exec.test after mdemo-static.test on GNU/Linux
(without any further modifications).  You can simulate need_lib_prefix
by help of the attached patch (which I won't apply ATM because I don't
know whether it's safe).  The patch creates a test which itself creates
a new build tree for Libtool, changes need_lib_prefix, configures mdemo,
(mdemo-conf, not mdemo-static), changes need_lib_prefix there, then
builds.  Adjust as needed.

I couldn't get your attached test to work, but I did it manually and produced the problem. The issue is that libltdl tries to compensate for the added prefix, and since we now strip that things break.

So it seems the smoothest course is to modify the preload routines in ltdl. I see two options here:

 * Keep the preload name in the new form. Have lt_dlopen(name) try first
   with name, then with lib_prefix + name.

 * Keep part of the new form, all but the need_lib_prefix logic. Have
   lt_dlopen(name) try first with name, then with lib_prefix + name,
   then with name where lib_prefix was removed.

Does this sound like an acceptable route?

Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web:

reply via email to

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