[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Use lt_dlopenext instead of lt_dlopen (ITS#2437)

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Howard Chu (hyc@highlandsun.com) wrote:
> What version of libtool are you talking about? In looking at libltdl from
> 1.4.2 and 1.4.3 I see nothing special about lt_dlopenext. You're always f=
> to specify a fully-qualified filename; since lt_dlopenext just calls
> lt_dlopen anyway, I don't see any particular advantage or limitation in t=
> current situation. If you want to omit the .la files and load the .so fil=
> directly, you're completely free to do so.
> If you can give a better explanation of exactly what you're unable to do =
> the current code, please do. Otherwise I think this ITS should be closed.

Ok, hopefully I can clear things up a bit, I think I may have opened two
ITS's on this so this may already be somewhere, but in any case:

lt_dlopenext() will pick the appropriate file to use from what's
available.  This means that you can be consistant across platforms with
the config even though the underlying file which is picked is different.
You could also just explicitly include the extension, that's true.

The bigger problem which I think I was running into originally is that
the names of the init_module functions are munged in the backends which
means that you can't just load the .so or the 'init_module' symbol won't
be found because it's 'back_monitor_LTX_init_module' or something.

Personally I'd encourage lt_dlopenext() since it should open the correct
file for the platform you're on but it's not a huge deal either way.
The bigger issue is the init_module function names in the backends.



Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.1 (GNU/Linux)