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?
Cheers.
--
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
Attachment:
pgpDPR7vf7RW9.pgp
Description: PGP signature