[Top][All Lists]

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

Re: Libtool API suggestion: LTDL_SHLIB_PRE and/or char* ltdl_map_shared_

From: Dalibor Topic
Subject: Re: Libtool API suggestion: LTDL_SHLIB_PRE and/or char* ltdl_map_shared_name(const char* name)
Date: Wed, 24 Aug 2005 21:53:44 +0200
User-agent: Debian Thunderbird 1.0.2 (X11/20050331)

Ralf Wildenhues wrote:
> * Dalibor Topic wrote on Tue, Aug 23, 2005 at 08:20:42PM CEST:
>>It would be nice if libtool provided a way to either map a short dynamic
>>library name to a full name (say, something -> or
>>offered an autoconfish way to get the platform-specifc shared library
>>prefix, like it does for the suffix.
>>I've seen that a similar problem occured for GNU readline on cygwin[1],
>>and they went for a platform-specific set of properties in the
>>makefiles. I guess it would be more efficient if libtool provided a
>>central API for that, rather than to see projects reinventing the wheel.
> OK.  I see the general idea as useful.

OK, so I am not totally off base, here. :)

> There's a couple of connected questions that have not been considered
> yet, though.  IOW: the problem space is not clear yet:
> Can we assume that each particular system has only one answer?

that's a tricky question: some operating environments (say win32) can
host multiple toolchains (say MSVC, cygwin & mingw32) with different
conventions wrt to the prefix choice (none, cyg & lib, I think).

I think it is safe to assume that within a toolchain the answer is
clear. I do not know how that works wrt to
cross-toolchain-interperability, though.

> Can libtool assume that all previously installed libraries obey this
> answer, when it goes searching for deplibs?

Whatever libtool does now wrt to prefixes, seems to work well enough.
Does it search for multiple, different prefixes atm?

> For example, Peter Ekberg's recent proposed patches do not prefix `lib'
> to libraries created with MSVC (which is similar to how other libs look
> on this system).  Now, ideally the user might want to be able to mix
> code created by this compiler with code created by GCC.  However,
> mingw/gcc has a different naming scheme.

Yeah. How does lt_dlopen(ext) deal with that atm?

> So, can we settle on one scheme per system, i.e., have a mapping
>   system -> libname_spec
> where everyone would be happy with?
> Another important question: are you even talking about libname_spec or
> about soname_spec?  You do know that the two are not so easily mixable
> on all systems (e.g., AIX)?

OK. I *think* I am talking about soname_spec, looking at libtool.m4. At
least in Cygwin's case. Looking at libtool.m4, the difference is not
very clear to me, as pw32 changes the prefix to libname_spec. :(

>>It also seems that ltdl.c uses the "lib" prefix specifically in one case
>>[2] , where it may or may not make sense to use a hypothetical
> ACK.  This is a bug.  Added to TODO list in Gary's wiki.


dalibor topic

reply via email to

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