Re: ocaml compiled binaries and rpath
On Fri, Apr 11, 2003 at 04:26:48PM +0200, Martin Pitt wrote:
> Hi Sven and all others,
>
> Am 2003-04-11 14:50 +0200 schrieb Sven Luther:
> > You just need to add a lintian override, you know how to do this ?
>
> No, I dit not, but thanks to your explanation, I do now. I installed
> the override, and it works fine.
>
> > > My current approach is to build a bytecode package (arch: all) for
> > > the "general case" (this would binary-depend on ocaml-base) and a
> > > package offering native versions for all platforms supporting it.
>
> > you need to call the bytecode version planet-byte, and have it
> > provide planet, and call the native code version planet. The
> > apt/dpkg magic will prefer a true package before an virtual one, so
> > if you install plant, you will get the native code version if it
> > exists and the bytecode version if it does not. installing
> > planet-byte will get you the bytecode version, no matter what.
> > Naturally, you have to have the two packages to conflict so they
> > don't install at the same time.
>
> I admit that I would have never conceived that on my own. But it works
> very well and I understand the principle now. Thanks for the detailled
> explanation.
>
> > Now, this suppose that you remove all the -custom flags that upstream
> > has used in the Makefiles,
>
> I already did, since otherwise I do not get real bytecode. -custom
> creates an ELF executable, without -custom real bytecode files with a
> shebang line is created.
>
> > and is not possible or good if you have C bindings included, like
> > the advi package does for example. The correct way is to either say
> > you don't care and package a -custom bytecode or a native code, both
> > arch: any, or to separate the binding library in its own package,
> > which will be arch: any and provide both the bytecode and nativecode
> > libraries, and build the app depending on this library.
>
> I do not fully understand that but I will investigate what C-Bindings in
> ocaml programs are.
Do you have any .c source, and does the result of the makefile run
produce any file of the kind dll***.so ?
C bindings are in reality composed of two pieces, one the so called
stublib is a small source file which wrapps calls to an external
C library to functions palatable by the ocaml-C interface, and the other
is the ocaml source file that makes calls to the stublib.
It is used for example in lablgtk, which is a ocaml gtk+ binding.
> > I would say the second only makes sense if the library can be used by
> > other people too, or if the app is really big that not having 5 extra
> > copies in the archive is a good thing.
>
> The application is pretty small (bytecode package: 324 kB). But if I
> understood you and the -custom flag correctly, -custom will create
> arch-specific pseudobytecode packages, whereas without -custom true
> arch-independent files are created (see above). Did I get this right?
Yes, but also there is another difference. If you remove the -custom
flag, the stub libs will be dynamically linked, and you have to depend
you package on the corresponding libfoo-ocaml package, while when using
the -custom flag, these stublibs will be statically linked to your
package, and thus you don't need to have the stublibs installed.
If there are stublibs in your package, and you install only the
executable, then the arch: all package will not work on any system but
yours. An easy way to test this is to install the package and then move
the directory you built it in (or just clean it). If the executable
works, it doesn't make use of internal stublibs.
> I will upload an updated version of my package in a few minutes.
To where ?
> BTW: I use ocaml from unstable now. :-)
:)))
> Thanks a lot!
No problem.
Friendly,
Sven Luther
Reply to: