Summary: | eselect-opengl uncovers broken libdir layouts on AMD64 platform | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dmitri Pogosian <pogosyan> |
Component: | Current packages | Assignee: | Jeremy Huddleston (RETIRED) <eradicator> |
Status: | RESOLVED DUPLICATE | ||
Severity: | critical | CC: | amd64, bigun, bug.hunter, elwood, eradicator, hoffbrinkle, x11-drivers |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Dmitri Pogosian
2006-07-03 14:17:54 UTC
A workaround, edit /usr/share/eselect/libs/multilib.bash and change ES_VALID_MULTILIB_DIRS="lib lib32 lib64" to ES_VALID_MULTILIB_DIRS="lib32 lib lib64" This seems to allow xorg-xserver to compile, for example. [The workaround just has the effect that the list_libdirs loops in eselect-opengl are done in 32-bit and then 64-bit order. For the loop which does the include directories [which ignores the lib64 because it is a link to lib] this means the 32 bit links are done first, then the "correct" links are done afterwards rather than doing 64-bit and then 32-bit] It's all too ugly, on all fronts, to find someone to blame or suggest a better fix :) A workaround, edit /usr/share/eselect/libs/multilib.bash and change ES_VALID_MULTILIB_DIRS="lib lib32 lib64" to ES_VALID_MULTILIB_DIRS="lib32 lib lib64" This seems to allow xorg-xserver to compile, for example. [The workaround just has the effect that the list_libdirs loops in eselect-opengl are done in 32-bit and then 64-bit order. For the loop which does the include directories [which ignores the lib64 because it is a link to lib] this means the 32 bit links are done first, then the "correct" links are done afterwards rather than doing 64-bit and then 32-bit] It's all too ugly, on all fronts, to find someone to blame or suggest a better fix :) (In reply to comment #1) This is actualy the least ugly workaround I was able to find :) Indeed, it seems just wrong to have lib32 in priority position over lib *** Bug 139695 has been marked as a duplicate of this bug. *** *** Bug 139691 has been marked as a duplicate of this bug. *** *** Bug 139908 has been marked as a duplicate of this bug. *** I guess this bug is not due to eselect-opengl at all. From comment #2 and conversation with Stuart, i deduce that people who hit this bug have acutally a broken setup: People, please check for your library setup. You should have /lib symlink to /lib64 /lib32 directory /lib64 directory Same goes for /usr/lib* /usr/lib symlink to /usr/lib64 /usr/lib32 directory /usr/lib64 directory Everything else is broken and should be fixed. AMD64 team will soon publish a guide how to do this. Sorry for all the inconvenience. If anybody is hitting the same bug with eselect-opengl and has a sane libdir setup as listed above, please file a new bug. (In reply to comment #7) > I guess this bug is not due to eselect-opengl at all. > From comment #2 and conversation with Stuart, i deduce that people who > hit this bug have acutally a broken setup: > > People, please check for your library setup. You should have > /lib symlink to /lib64 > /lib32 directory > /lib64 directory > > Same goes for /usr/lib* > /usr/lib symlink to /usr/lib64 > /usr/lib32 directory > /usr/lib64 directory > > Everything else is broken and should be fixed. AMD64 team will soon publish > a guide how to do this. Sorry for all the inconvenience. > > If anybody is hitting the same bug with eselect-opengl and has a sane libdir > setup as listed above, please file a new bug. > Yes indeed, I have lib - directory lib32 - directory lib64 - symlink to lib and /usr/lib - directory /usr/lib32 - directory /usr/lib64 - symlink to /usr/lib However, I vaguely remember that when 2006.0 (2005.1 ??) profile appeared there was some discussion that the directory structure is changed and that 2006.0 is converted to a 'proper' one. Isn't it what you propose is what was in place before the recent profiles ? > However, I vaguely remember that when 2006.0 (2005.1 ??) profile appeared there
> was some discussion that the directory structure is changed and that 2006.0 is
> converted to a 'proper' one. Isn't it what you propose is what was in place
> before the recent profiles ?
>
I may not remember the dates correctly, and I did not find an explicit statement on Gentoo website as to what structure is considered standard, but a web search shows that there was a lot of heated discussions 1-1.5 years ago whether lib should be real and lib64 symlink or wise-versa (with the reference to AMD64 ABI guidelines). Moreover plenty of Web sites claim that Redhat and Suse use real lib64 and lib is a symlink, while Gentoo, Debian and Ubintu use an opposite convention.
It would be good to know when Gentoo-amd64 changed its mind, since I was just dutifully updating profiles, never manually changing the directory structure.
looks like bug 132135 to me *** This bug has been marked as a duplicate of 132135 *** |