[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: Ralf Wildenhues
Subject: Re: Libtool API suggestion: LTDL_SHLIB_PRE and/or char* ltdl_map_shared_name(const char* name)
Date: Wed, 24 Aug 2005 09:23:32 +0200
User-agent: Mutt/1.4.1i

* 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.

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?
Can libtool assume that all previously installed libraries obey this
answer, when it goes searching for deplibs?

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.

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)?

See also the proposed generalization by Keith Packard to allow a
different soname.

> 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.


reply via email to

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