On Sun, Sep 08, 2002 at 03:13:19PM +0200, Goswin Brederlow wrote: > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > On Sun, Sep 08, 2002 at 02:34:45AM +0200, Goswin Brederlow wrote: > > > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > > > > > Upstream choose to use rpath, and when i asked on d-m, a huge flameware > > > > about the usage of rpath followed, which didn't give me a conclusive > > > > answer in any direction. Upstream mostly ignored my question (well they > > > > responded, but they like rpath). > > > > > > The problem with rpath, as far as I gathered from various falmes, is > > > that you depend on the library your build with. Slight changes of the > > > libraries make the binary unusable, like moving the library or version > > > changes. Without rpath it still find the library. > > > > Yes, do you want to argue with upstream ? > > No, just fix the debian package of ocaml.
Please, submit a patch about it, and i will consider applying it ... More seriously, as i have no idea how the rpath stuff works internally, i am very badly placed about doing this kind of work, don't you think ? > > > > > 2. mldonkey uses ocamlopt.opt but ocamlopt works as well. Which of the > > > > > two should I use? Should I build-depend on eigther or conflict with > > > > > one? > > > > > > > > You should build depend on ocaml-best-compilers, and do a test for the > > > > presence of ocamlopt.opt before using it. > > > > > > > > Make sure you have a fallback to use bytecode (ocamlc) if ocamlopt is > > > > not present, or you will get _plenty_ of bug report, as your package > > > > will _not_ build on m68k, hppa, mips, mipsel and maybe some other i am > > > > missing. > > > > > > When I do "make byte" I still get an elf binary. Is there a way to > > > make a binary-all ocaml program? Since its bytecode it seems like a > > > big waste to have the same bytecode for every arch. > > > > Remove the -custom option. > > Great. I will build a bytecode binary-all and a optimised with > arch=i386,alpha,...<archs that have ocamlopt>. Yes, you could also split the package in two binaries, the first one being a bytecode package, and arch: all, the other being a native code package and arch: <list of supported arches>. the second one would divert the binaries of the first one, or something such. Friendly, Sven Luther
