Re: stublibs and bytecode only packages. Was: Re: Plans [Re: Cameleon 1.0]
On Fri, Sep 06, 2002 at 05:12:51PM +0200, Stefano Zacchiroli wrote:
> On Thu, Sep 05, 2002 at 02:33:06PM +0200, Sven LUTHER wrote:
> > Mmm, remember that adding dynamic loading stublibs also has the
> > advantage of making the resulting bytecode program arch: all, that is
> > the exact same binary can run on all arches, so i would suggest to build
> > dynamic loading stublibs anytime it is possible, and separate them in
> > their own package.
>
> I know a few regading these issues, anyway shared object (.so) are not
> architecture independent, right? We still have to rebuild them an all
> architectures.
> Indeed:
>
> # file /usr/lib/ocaml/stublibs/dllbigarray.so
> /usr/lib/ocaml/stublibs/dllbigarray.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
> (note the Intel 80386)
>
> The only stuff that is architecture independent is dynamic loading of
> pure ocaml .cm{o,a}, right again?
>
> Then looking at packages of mine, I have pairs of lib***-ocaml{,-dev}
> files, but in all of them the dynloading stuff contains at least one .so
> shared object ... in this way the splitting between -dev and non-dev let
> us gain nothing.
>
> Am I missing something?
Well, the main point is that if a library use C stubs, and does not
provide dll.so shared objects (only the .a ones) then you have to build
executables using them with the -custom flag, and the resulting bytecode
object is arch dependant.
One of the big benefits of the new (in 3.04) dll.so loading scheme, is
that bytecode executable using dynamic loading stublibs again become
architecture independent :
sven: a /usr/bin/ocamlrun script text executable
This means that i could well build a version of ledit which is arch: all,
let me try ...
current ledit, use -custom to link :
$ file /usr/bin/ledit
/usr/bin/ledit: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), not stripped
Rebuilt ledit, without the -custom flag :
$ file /usr/bin/ledit
/usr/bin/ledit: a /usr/bin/ocamlrun script text executable
But it now depends on ocaml-base, for dllunix.so :
$ mv /usr/lib/ocaml/ld.conf /tmp
$ ledit
Fatal error: cannot load shared library dllunix
Reason: dllunix.so: cannot open shared object file: No such file or directory
So, it is arch all, but it depends on ocaml-base.
Ledit (with -custom) is Size: 98054.
Ocaml-base is Size: 166000.
Ledit (without -custom) is Size: 25850.
So we gain 73Ko in the archive for i386 alone and if we multiply this
for all supported archs, some of them even having bigger object size
(powerpc for example) we may well save around 1 Mo archive space for
this program alone, not counting the time needed to build it on all
archives. The downside is that people wanting ledit and not having any
use for ocaml would have to download 197850 of .debs instead of just
98054.
Notice that this works well because ledit is built bytecode only, since
it is not a speed hungry program.
Friendly,
Sven Luther
Reply to: