| Summary: | app-eselect/eselect-mesa: does not respect libdir | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | alexander, arthur, dschridde+gentoobugs, floppym, haavardw, jcallen, kaikaikai, multilib+disabled, nikoli, pacho, pastas4, polynomial-c, qa, tsmksubc, tsmx |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=576334 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 506276 | ||
| Attachments: | Properly hand SYMLINK_LIB=no | ||
(In reply to Michał Górny from comment #0) > This is definitely incorrect and breaks systems with 'modern' multilib. And systems with SYMLINK_LIB=no (bug 506276) It seems like this eselect module assumes there will only ever be two ABIs; mips has three. This could use a bit of work. I'll see what I can do. (In reply to Mike Gilbert from comment #2) x86 has three too ;) Created attachment 426040 [details, diff]
Properly hand SYMLINK_LIB=no
I'm sorry about sitting with this in my github bug staging overlay for, err years... While that solves the x32 issue, it's... still pretty ugly. For one, calling the other two options "32bit" and "64bit" is wrong to begin with; x32 is technically 32bit too. They should either be called by archs ("x86" and "amd64"), or by ABI_X86 and /usr/lib* names ("32" and "64").
In addition, instead of copying everything, maybe it could generate the list of all ABIs on the fly, to prevent the same issue happening as soon as another ABI is added (or removed)? I think that was the original idea of this bug report to begin with. And just checking whether /usr/lib is a symlink sounds rather fragile to me.
Also, I think this bug report should also block the x32 tracker bug.
I have done some more extensive changes to this, I just forgot about them for a year. https://github.com/floppym/eselect/commits/extern After consulting with the X11 team, we agreed that the 32bit and 64bit options are rather pointless, so I removed them. Instead, all configured libdirs are updated in-sync. The ebuild will need to be adjusted to replace LIBDIRS=( lib ) with the real list if libdirs configured in the profile at build time. So what's the plan forward now? Nuke eselect-mesa altogether? (In reply to Mike Gilbert from comment #7) > The ebuild will need to be adjusted to replace LIBDIRS=( lib ) with the real > list if libdirs configured in the profile at build time. This should be implemented in app-admin/eselect and reused by other modules. Currently the list of libdirs is hardcoded [1]: ES_VALID_MULTILIB_DIRS="lib lib32 lib64 libx32" [1] https://gitweb.gentoo.org/proj/eselect.git/tree/libs/multilib.bash.in (In reply to Alexander Tsoy from comment #9) Good point. I forgot eselect had a library for this. *** Bug 645148 has been marked as a duplicate of this bug. *** This is a very frustrating bug. It took me a couple of days to figure out what the problem with the opengl apps is... An update broke the opengl apps. Because of this bug, in eselect mesa I see teres ~ # eselect mesa list i915 (Intel 915, 945) i965 (Intel GMA 965, G/Q3x, G/Q4x, HD) r300 (Radeon R300-R500) r600 (Radeon R600-R700, Evergreen, Northern Islands) sw (Software renderer) teres ~ # eselect mesa show teres ~ The bug is around for over 4 years. Should it get fixed? Should be fixed by https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2411166e5 |
MESA_DIR_64="${EROOT}/usr/lib/mesa" DRI_DIR_64="${EROOT}/usr/lib/dri" This is definitely incorrect and breaks systems with 'modern' multilib.