On Wed, Aug 16, 2006, Caleb Epstein wrote:
> On 8/16/06, Ralf S. Engelschall <[EMAIL PROTECTED]> wrote:
>
> >> Besides, I found out, that many (all?) openpkg packages are configured
> >> with the "--disable-shared" option which causes them not to produce
> >> any shared library. What is the reason for that?
> >
> >That's because there is no _portable_ way to build and link applications
> >against shared libraries _AND_ make sure that those applications really
> >load the correct libraries under run-time in case you have multiple
> >installations on a single platform (OpenPKG's major multiple-instance
> >feature). I know that there is GNU libtool and on ELF based platforms
>
> Just out of curiosity, how many folks actually *use* this feature?
You mean the "multiple instance" feature of OpenPKG. Well, I've no
numbers at hand. I can only say that if people are using OpenPKG but
*not* using this major feature they are either very frugal or do
something wrong because they have not understood the great power behind
this OpenPKG feature. For me beside the cross-platform support of
OpenPKG, the multiple-instance feature is one of the major technical
features and design goals of OpenPKG.
I guess I am misunderstanding what "multiple instance" means. Does it mean you can have more than one comlpete OpenPKG instance ( e.g. different OpenPKG versions with full sets of packages) installed at once, or does it mean that you can have multiple instances of package <X> installed in one OpenPKG instance (e.g. textutils 1.11 and 1.12 and 1.13 and ...)? Or is it something else entirely.
> I know I personally would prefer having shared objects to being able
> to have multiple independent versions of OpenPKG installed on a
> machine.
This I do not understand. Why do you need shared objects in order to
have "multiple independent versions of OpenPKG installed"? The existing
support for multiple instances in OpenPKG _is_ exactly what allows you
to do this -- and fully without any shared objects. So, I guess I'm
misunderstanding your point here.
I wasn't suggesting that you couldn't do this with OpenPKG as it stands, just wondering if anyone *does* do this. But again I may be misunderstanding what you mean by "multiple instances" so I'm not sure we are talking about the same thing.
> That lack of shared libraries/objects increases the memory and disk
> space requirements
Yes and no. It certainly increases disk space requirements, yes. But
disk space costs nearly nothing already since years. And although the
memory space requirement is slightly increased, this isn't really such
much as we still link system libraries dynamically and only our own
OpenPKG ones statically into applications. So, the slightly increased
resource consumption certainly is true in theory, during many years
in server computing I've _never_ seen a server system I've reviewed
which was based on OpenPKG and which had a resource bottleneck caused by
_those_ issues. So, IMHO this slight resource increase can be neglected.
There is also the issue of needing to recompile applications whenever a library they link with has changed. For example, lets take libxml2. Many applications link with this library. If a bug is found and fixed, all of those applications will require relinking using the current scheme. If the bug fix did not change the public interface to the library, and shared libraries were used, no applications would require relinking to pick up the fix.
> for OpenPKG and even breaks, to some small degree,
> certain applications. The awesome zsh shell, for example, needs
> shared library support for its loadable modules.
Sorry, you are intermixing two points here. Loadable modules and shared
libraries are two different species: the first ones are DSOs which are
_explicitly_ loaded by an application and OpenPKG uses this in many
packages (if our "zsh" package still doesn't feel free to add this
feature) as it doesn't break any of OpenPKG's features. The second
ones are DSOs which are _implicitly_ loaded by the Unix run-time loader
(RTLD) for an application and OpenPKG doesn't use this as it breaks
some of OpenPKG's major features like support for multiple instances.
Shared libraries and loadable modules are nearly identical in that they are built using the same tools and compiler switches. OpenPKG's use of "--disable-shared" when calling configure causes zsh at least to omit its loadable module support, which causes certain features not to work (for example programmable completion). I think this would be true of most applications that use configure and libtool to build their DSOs.
So, we have to be precise here: OpenPKG is neither about statically
linked applications (we always link the executables _dynamically_, we
just link in our own libraries statically), nor is it about not using
Dynamic Shared Objects (DSO) at all (we use it for applications which do
their own libtool or dlopen stuff). OpenPKG currently just about _NOT_
using shared libraries (i.e. <prefix>/lib/libfoo.so's)
How are those applications configured? They still build/use dynamic loading when --disable-shared is passed to configure?
Well, I also would like to see _optional_ shared library support for
OpenPKG since a longer time. I can only say that until now I still do
not see how we can achieve this with more advantages (usually under
run-time) than disadvantages (usually under packaging/build-time). But,
hey, perhaps someone has a rather clever idea how we can add optional
shared library support without having to poke dozen of %if's into
hundreds of packages.
Shouldn't it be as simple as not passing --disable-shared to configure in most cases?
At least until know I think that most people seem to overestimate the
effective benefit of shared library support....
know = now? Has something changed your mind?
Caleb Epstein
