[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 -> libsomething.so) 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
>>LTDL_SHLIB_PRE.
>
>
> ACK. This is a bug. Added to TODO list in Gary's wiki.
Thanks!
cheers,
dalibor topic