[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ocaml compiled binaries and rpath



On Fri, Apr 11, 2003 at 01:35:10PM +0200, Martin Pitt wrote:
> Hi Sven and all others,
> 
> Am 2003-04-11 12:27 +0200 schrieb Sven Luther:
> > > Another DD pointed me at the tool "chrpath" which is able to remove
> > > the RPATH in a library. Would you recommend using that?
> > 
> > ... well, i don't think i would recomend it, since the ocaml situation
> > is a bit different from the C situation. 
> 
> Claudio's recent mail seems to settle that issue. I'll forget about
> the rpath; I'm perfectly happy with this solution, I just wanted to
> settle that issue before offering a package with lintian bugs.

You just need to add a lintian override, you know how to do this ? you
just need to install a file containing the lintian reports as for
example :

liblablgl-ocaml: binary-or-shlib-defines-rpath ./usr/lib/ocaml/3.06/stublibs/dlllablgl.so /usr/X11R6/lib
liblablgl-ocaml: binary-or-shlib-defines-rpath ./usr/lib/ocaml/3.06/stublibs/dlltogl.so /usr/X11R6/lib

into :

$(CURDIR)/debian/liblablgl-ocaml/usr/share/lintian/overrides/liblablgl-ocaml

Changing the lablgl package name for your own, that is.

> > Mmm, i suppose you are building on i386 only and thus producing
> > native code executables, you are aware that this will break on all
> > the arches where the native code is not supported (m68k, hppa, s390,
> > mips, mipsel i think).
> 
> I'm aware of that issue. 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.

A, ok, use spamoracle as example it does exactly this, and was my
testbed for this thing.

> AFAIK there is a possibility to achieve that with package diversions.
> Up to now I do not know anything about that (I'm a beginner, after
> all), but I will RTFM and tinker until I'm enlightened :-)

No need, 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.

Now, this suppose that you remove all the -custom flags that upstream
has used in the Makefiles, 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 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.

Maybe you could post the lintian warnings and the description of the
package ?

> > > 	http://www.piware.de/Sources.gz
> > 
> > Ok, i will look at it.
> 
> Thanks! As I already said: only native compiling up to now, but that's
> going to change.

Yes.

> > I will have to update it. BTW, you are using the sid ocaml packages,
> > right ?
> 
> I admit that I'm still using the testing version up to now (due to my
> slow modem net connection). But if it seems advisable, I can apt-pin
> to the unstable one, of course.

Well, there are two considerations, first if you want to upload the
package, it will go into sid, and should be built with a sid system. You
can build it with pbuilder though, so you don't necessarily need to run
sid yourself. Second, the testing packages are obsolet, even woody has
never packages, and as said, the ocaml 3.06 package are ready for
testing/sarge, and have been in mini-freeze for month, just waiting for
postgresql and libvorbis bugs to be solved, which doesn't influence your
use of the ocaml packages at all, since you don't use either
libpgsql-ocaml nor ocamlsdl, right ?

Friendly,

Sven Luther
> 
> Thank you for your help!
> 
> Martin
> -- 
> Martin Pitt
> home:  www.piware.de
> eMail: martin@piware.de
> 
> Verteidigen Sie Ihre Freiheit und Ihre Rechte! Stoppt TCPA!
> Defend your freedom and your rights! Stop TCPA!
> http://www.notcpa.org




Reply to: