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