| 1 |
On Saturday 03 of April 2010 12:56:04 Fabian Groffen wrote: |
| 2 |
> Is it known why this does happen exactly? When a lib is kept because it |
| 3 |
> is still used, only its soname + what the soname points to should be |
| 4 |
> kept. That would mean the lib can no longer be found during linking, |
| 5 |
> unless you add some trickery (or does GNU ld do something "handy" out of |
| 6 |
> the box right here?). So for example: |
| 7 |
> |
| 8 |
> % ls |
| 9 |
> usr/lib/libfoo.so -> libfoo.so.2.1 |
| 10 |
> usr/lib/libfoo.so.2 -> libfoo.so.2.1 |
| 11 |
> usr/lib/libfoo.so.2.1 |
| 12 |
> |
| 13 |
> % scanelf --soname usr/lib/libfoo.so |
| 14 |
> libfoo.so.2 usr/lib/libfoo.so |
| 15 |
> |
| 16 |
> what should kept preserved is: |
| 17 |
> |
| 18 |
> usr/lib/libfoo.so.2 -> libfoo.so.2.1 |
| 19 |
> usr/lib/libfoo.so.2.1 |
| 20 |
> |
| 21 |
> because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should |
| 22 |
> (in theory and on some platforms at least) fail. |
| 23 |
|
| 24 |
It doesn't matter, as 'broken' build system may alphabetically find library by |
| 25 |
file name, and link to this library by full path. |
| 26 |
|
| 27 |
On Saturday 03 of April 2010 13:13:00 Michał Górny wrote: |
| 28 |
> > 2. During "emerge", unset environment variable corresponding to said |
| 29 |
> > preserved library directory - orphans are no longer located. |
| 30 |
> Wouldn't that cause failure when the toolkit relies on a 'hidden' |
| 31 |
> preserved library? |
| 32 |
|
| 33 |
It would indeed. Now when I think about it, moving stuff to preserved library |
| 34 |
dir could be just done - provided it's possible - along with fixing/setting |
| 35 |
DT_RPATH's in reverse runtime dependencies. This way no system-wide |
| 36 |
LIBRARY_PATH's would be necessary. |
| 37 |
Is it possible? Mike? |
| 38 |
|
| 39 |
On Saturday 03 of April 2010 13:33:16 Gilles Dartiguelongue wrote: |
| 40 |
> > There is opt-out suggestion[2], unfortunately it does not provide any |
| 41 |
> > info how exactly it's supposed to be achieved. As far as portage/pkgcore |
| 42 |
> > is concerned, maybe - as Brian Harring suggested - sandbox could be used |
| 43 |
> > to somehow "hide" preserved libraries or preserved library directory |
| 44 |
> > from ebuild environment (preserved library directory a'ka "purgatory" - |
| 45 |
> > libs could be moved there when considered orphaned). |
| 46 |
> that sounds nice, it would allow us to more easily spot |
| 47 |
> packages/upstreams doing it wrong (maybe that would work for packages |
| 48 |
> linking to themselves too btw) |
| 49 |
|
| 50 |
Keeping preserved libraries in separate location (in "purgatory" or dumping |
| 51 |
place) is just a method for making implementation possibly easier (or possible |
| 52 |
at all), with nice side effects though. |
| 53 |
|
| 54 |
-- |
| 55 |
regards |
| 56 |
MM |
Archives