Hello! Jan Nieuwenhuizen <janneke-l...@xs4all.nl> writes:
> Ludovic Courtès schreef op za 29-01-2011 om 22:39 [+0100]: [...] >> I’m not sure about this patch. My feeling is that it would take more >> than this to allow Guile to be truly relocatable, e.g., all of >> $GUILE_LOAD_PATH, $GUILE_LOAD_COMPILED_PATH, $LD_LIBRARY_PATH, >> etc. would have to work. > > I realised we need GUILE_LOAD_COMPILED_PATH too. Added that > in this new patch. I added a bit more explanation: this should > be used together with a sane -rpath $ORIGIN/../lib build. Ooh, I see. $ORIGIN is the trick that makes it possible. Your patch lacks this RPATH magic, though. Perhaps it should check whether ‘-Wl,-rpath='$ORIGIN/../lib'’ works? Is ‘-Wl,-z -Wl,origin’ needed as well when linking ‘guile’? >> And some of them are hardcoded in the binary, >> as is usual with the GNU Build System. > > Yes, that's why the new, argv0-based directories are prepended > to those paths. OK, understood. >> Furthermore, I think all these paths cannot be reliably inferred from >> argv[0]. For instance because libdir doesn’t have to be $bindir/../lib. >> It doesn’t seem to fit well in the GNU software installation process. > > No, you can choose all kinds of freaky install directories. However, > if you don't do that and use the normal, default directory structure, > this enables binary packages with guile that can be installed in > $HOME or on Windows in c:/Program Files/Whatever. Yes, that’s what I meant: it only works as long as users touch only $prefix, not $libdir, $bindir, etc. >> Still I’d be glad to hear arguments for and against. :-) > > One argument for is that we've been using this in LilyPond binary > packages (for linux and windows) since 2005. Good point. :-) Then I have nothing against this option, as long as it’s off by default. Thanks, Ludo’.
