Peter Eisentraut <peter_e@gmx.net> writes:
> Trond Eivind Glomsrød writes:
>
> > > There are provisions in the source for figuring this out automatically.
> > > Currently, the only "figuring" it does is to allow it on Linux. (It is my
> > > understanding that it works on Linux independent of the CPU architecture.
> > > In the past there have been problems with insufficient dynamic loader
> > > implementations, but there is no principal design obstacle.)
> >
> > No. It works on IA32, but breaks elsewhere.
>
> Libtool seems to think otherwise. And the people who provided the
> patches to libtool are the ones who should know best.
Dynamic code works on those platforms. What doesn't work is dlopen()
of code not compiled with -fpic (which means extensions linking with
static libraries). I've not seen libtool claim otherwise, but it would
be broken. Another can of worms is nsswitch inside glibc, which in
some circumstances will use a dynamic module in a statically linked
program.
> > > But it would really be of advantage if distributors (i.e., you) supplied a
> > > shared libperl by default. There are at least two high profile users
> > > (PostgreSQL and Apache) running into this problem.
> >
> > It's not unlikely to happen for the next major series (we try hard to
> > stay binary compatible within a series).
>
> You don't break binary compatibility by providing a shared library
> alongside a static one.
This mean backward as well... eg. perl packages for RHL 7.1 should run
on RHL 7 as well. Same for RHL 7.2, if we make such a release.
--
Trond Eivind Glomsrød
Red Hat, Inc.