On Mon, Sep 09, 2002 at 12:16:22PM +0200, Goswin Brederlow wrote: > Sven LUTHER <[EMAIL PROTECTED]> writes: > > > 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 ? > > Same here. I greped the source and it seems rpath is only in 3 files, > only of them source. rpath is in the configure stuff, so there might > be a compiletime option to turn it off already.
There is the -rpath option to the ocamlc compiler which knows about this. > Its low on my todo list. I will ignore it till something breaks, > someone complains or I get bored. Well, keep in mind that the bytecode library generation is a complex thing, that the -rpath may break other things that are not evident at first, and that, if possible, we should not change our stuff very much from the upstream version. Mostly they are much more competent than us on this, and know more exactly about it. If you want to remove the -rpath, then we should get at lest their agreement or opinion on this. > > the second one would divert the binaries of the first one, or something > > such. > > mldonkey is a start script (doing a cd and starting the real mldonkey), > the mldonkey and 2 small example files. I think packages that conflict > would be good enough. Making them coexist or divert each other > probably uses more space than duplicate example files and startup > script. I don't think someone wants the bytecompile and optimised on > the same system. Ok, it's up to you. (But if they divert, then it is easier to make speed comparison between them :))) Friendly, Sven Luther > > MfG > Goswin
