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 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.
> Clearly its HARD to do the latter thing right with shared
> libs, but its certainly not impossible.
Yes, of course. Nothing is impossible. Everything is just a matter of
two issues: implementation costs (here hacking the DSO support into many
packages) and new drawbacks resulting from the implementation (here for
instance the required hacks itself which might cause simple packages to
become rather complex and less easy to maintain).
> 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.
> 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.
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)
> I'd rather have shared libs, but its Ralf's ship to steer. What do
> others think?
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.
At least until know I think that most people seem to overestimate the
effective benefit of shared library support....
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List openpkg-users@openpkg.org
