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