Le Monday 18 August 2008 17:46:50 Xavier Leroy, vous avez écrit : > First, the bug summary is incorrect: it's not all ocaml-generated > executables that cannot be stripped, but only those generated by the > now-obsolete "ocamlc -custom" option. The latter builds a mixed > bytecode/native C executable, but this approach has been deprecated in > favor of putting the C stub code in shared libraries which are then > loaded by the pure bytecode executable.
Ok, I have tried to compile an example here are my conclusions, please correct me if I am wrong: * When linking against an ocaml module, the .cmo file is needed. This is clearly not the case in a majority of ocaml packages, if not all of them. * When using the .cma file, compilation is made in -custom mode, even *without* passing the option * You need to provide the -dllib /path/to/dllmodule_stubs.so option * What is the mechanism used to load the stubs.so ? I believe it is some sort of "dlopen", but I can't find a hardcoded path in the resulting object. * This binary dependency won't be noticed by our shlibdeps system since it does not relly on ELF and NEEDED headers. * I can't make ocamlfind to compile such binaries, appart from passing manually all the required options... All of this makes me think that it is still hard to switch to this. Also, it will be some work to catch and define a good packaging policy for this compilation mode. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
