[Top][All Lists]

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

libtool-1.5.20 -- lt_dlopenext fails to open preloaded module

From: Peter Breitenlohner
Subject: libtool-1.5.20 -- lt_dlopenext fails to open preloaded module
Date: Mon, 7 Nov 2005 18:35:43 +0100 (CET)

Recently I hacked together a small package in order to demonstrate how
libtool works (using autoconf-2.95, automake-1.9.6, and libtool-1.5.20).

I did all this on a linux-gnu system perfectly capable to dlopen modules,
but prevented that to happen by configuring with "--disable-shared".
In order to compensate for that, I added this
        app1_LDFLAGS = -export-dynamic \
                -dlopen ../modules/mod1.la \
                -dlopen ../modules/mod2.la -L$(moddir)
to the Makefile.am responsible for building a test program "app1" that was
supposed to dlopen the (installed or uninstalled) modules "mod1" and "mod2".

The test program failed with both
and only
did succeed.

Looking at the code it was clear why lt_dlopenext failed in this case (but
succeeded with "--enable-shared"). Since neither "mod1" nor "mod1.a" has one
of the extensions ".la" or ".so", lt_dlopenext tried to append them. But in
the situation described, there is only "mod1.a" built into the test program
(no "mod1.so" and no "mod1.la").

If I correctly understand the rationale for lt_dlopenext, the purpose is
precisely to hide such details from the user.

Looking at the code I saw no easy fix for the above problem. Maybe the best
strategy would be that "presym_open()" changes the extension of the FILENAME
given to it from ".la" to ".a". That way lt_dlopen("mod1.la") would equally
succeed to locate the preopened module "mod1.a" -- probably in the spirit of

Peter Breitenlohner <address@hidden>

reply via email to

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