Bug#256900: Ocaml compiled programs cannot be stripped
On Wed, Aug 20, 2008 at 05:19:17PM +0200, Xavier Leroy wrote:
> Hello Sven,
> >>> 1- "ocamlc -custom" is deprecated and packages that use it should be fixed.
> >> If this option is deprecated, i think we should handle it so for all
> >> debian package. See at the end of the mail for a proposed way of doing
> >> thing.
> > One question though which comes to mind while reading this thread. When
> > was the -custom version deprecated, and what does this imply for the
> > version of ocaml in debian which will ship with lenny.
> OK, maybe "deprecated" isn't the right word.
> The -custom option is not deprecated in the sense of "it will be
> removed at some point in the future". We Caml people take backward
> compatibility very very seriously. This option is here to stay,
> but not to be improved, because:
Well, let's rephrase this, since when is the shared stub way
"recomended" over the -custom version. This was the first time that i
really heard about this, altough i have been trying to do away with the
-custom flag in projects since some time.
Often folk only use -custom to do away with the dependencies, and kind
of create a "static" version of the binary, which is easier to install
standalone, which is not the debian use-case.
> The -custom option is deprecated in the sense that, since the
> introduction of dynamic loading of stub libraries in the bytecode
> interpreter circa 2001, there exists a much better alternative:
> put the native stubs into shared libraries and produce "pure" bytecode
> executables that dynamically load these libraries. This is better
> than -custom for several reasons:
> - smaller executables;
> - bytecode executables can be shared across different platforms;
> - it is possible to use such mixed Caml/native libraries from the toplevel.
> So, I think everyone should be gently encouraged to use shared libs
> instead of -custom. Especially since, as I mentioned earlier, some
> Caml projects that started before 2001 still force -custom when
> linking with standard libraries like unix.cma or str.cma, while this
> is now entirely unnecessary.
> Hope this addresses your concerns.
So, are you officially "gently encouraging" ? Is the community really
aware of your position ?