On 03-04-2010 14:09:42 +0200, Maciej Mrozowski wrote: > > because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should > > (in theory and on some platforms at least) fail. > > It doesn't matter, as 'broken' build system may alphabetically find > library by file name, and link to this library by full path.
Shouldn't we fix that buildsystem then? Do you have an example of a package/buildsystem that does that? > On Saturday 03 of April 2010 13:13:00 Michał Górny wrote: > > > 2. During "emerge", unset environment variable corresponding to said > > > preserved library directory - orphans are no longer located. > > Wouldn't that cause failure when the toolkit relies on a 'hidden' > > preserved library? > > It would indeed. Now when I think about it, moving stuff to preserved library > dir could be just done - provided it's possible - along with fixing/setting > DT_RPATH's in reverse runtime dependencies. This way no system-wide > LIBRARY_PATH's would be necessary. > Is it possible? Mike? No, unless you somehow make sure you reserve space for this, by e.g. setting a bogus rpath entry at buildtime. If you want to go that route, you probably want to look at the Prefix' binutils-config wrapper that already calls the linker with added rpath arguments. Afterwards you can use chrpath to set it to the correct location. Will get messy with the vdb though, but if Portage's doing it, it can probably be dealt with. -- Fabian Groffen Gentoo on a different level
