Re: Preloading without .la

[Pierre Ossman]

I upgraded to libtool 2 the other day and was hit by this bug again.
Has there been any work on fixing this rather large hole in the preload
functionality?

On Tue, 22 Aug 2006 16:20:01 +0200
Pierre Ossman <address@hidden> wrote:

> Another reminder...
> 
> Pierre Ossman wrote:
> > I guess this issue got lost somewhere. As the issue persists for me and
> > I'd rather not use a homebrew build environment, I'd still like this to
> > be resolved.
> > 
> > Rgds
> > Pierre
> > 
> > Pierre Ossman wrote:
> >> 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.
> >>> *snip*
> >>>
> >>> 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:
> >>> Yep.
> >>>
> >>>> 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("module.la") 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?
> >>
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > http://lists.gnu.org/mailman/listinfo/libtool
> 
> 


-- 
Pierre Ossman            OpenSource-based Thin Client Technology
System Developer         Telephone: +46-13-21 46 00
Cendio AB                Web: http://www.cendio.com

signature.asc
Description: PGP signature