FS#74364 - [mesa-amber] Wrong library filenames breaks GLX

Attached to Project: Arch Linux
Opened by Eduardo Escobar (eduardoeae) - Wednesday, 06 April 2022, 00:58 GMT
Last edited by Toolybird (Toolybird) - Friday, 26 May 2023, 05:47 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Laurent Carlier (lordheavy)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Apps using GLX fails because libraries and symlinks are named "amber" instead of "mesa" in mesa-amber (21.3.8-4)

Example log of glxinfo:
[code]
name of display: :0
Error: couldn't find RGB GLX visual or fbconfig
[/code]

All the libraries are called libGLX_amber.so when they should be libGLX_mesa.so
This task depends upon

Closed by  Toolybird (Toolybird)
Friday, 26 May 2023, 05:47 GMT
Reason for closing:  Fixed
Additional comments about closing:  mesa-amber 21.3.8-5
lib32-mesa-amber 21.3.9-5
Comment by Eduardo Escobar (eduardoeae) - Wednesday, 06 April 2022, 01:27 GMT
I've realized that libEGL files are also named "amber" but don't cause any problem with egl, as far as I can see.
Symlinking to libGLX_mesa appears to solve the "amber" problem
Comment by AK (Andreaskem) - Wednesday, 06 April 2022, 06:37 GMT
Do you have a weird option set in your xorg.conf? GlxVendorLibrary or something? (But that seems to default to "mesa", so maybe you have to configure it?)
Comment by Eduardo Escobar (eduardoeae) - Wednesday, 06 April 2022, 07:28 GMT
I had files in /etc/X11/xorg.conf.d (though nothing like GlxVendorLibrary), but I moved them when trying to troubleshoot this and it didn't work.
Symlinking all the libGLX_amber.so* libraries to libGLX_mesa.so* fixed it.
Comment by Eduardo Escobar (eduardoeae) - Wednesday, 06 April 2022, 07:48 GMT
ldd shows that, for example, picom (one of the apps that failed) is linked not to libGLX_mesa.so.0, but to libGLX.so.0 which is owned by libglvnd.
Maybe this is a libglvnd bug?
Comment by Jaron Kent-Dobias (pants) - Wednesday, 13 April 2022, 10:27 GMT
This causes problems with Mathematica (not officially supported, but nonetheless) of the kind:

Qt issued a fatal error: Could not initialize GLX

Qt tried to load plugins from:
/opt/Mathematica/SystemFiles/Libraries/Linux-x86-64/Qt/plugins
/opt/Mathematica/SystemFiles/FrontEnd/Binaries/Linux-x86-64

Creating the symlinks described above fixes the problem for me.
Comment by Seongbin Lim (sbinnee) - Friday, 29 April 2022, 09:59 GMT
I realized picom failure as well
Comment by Martin Schnitkemper (Martin-MS) - Monday, 02 May 2022, 08:00 GMT
I faced similar problems on a Lenovo-T400 with a "Mesa DRI Mobile Intel® GM45 Express Chipset". After I lost unexpected hardware acceleration due to a missing i965_dri.so I replaced the "mesa"-packge with "mesa-amber" and after that, I was no longer able to start the kde desktop due to a crashing sddm or startplasma-x11.

After I extended the package-section of PKGBUILD with the mentioned symlinks, removed the "amber"-stuff

| cd "${pkgdir}/usr/lib"
|
| for F in {EGL,GLX}
|
| do
| mv lib$F"_amber.so.0.0.0" lib$F"_mesa.so.0.0.0"
| ln -sv lib$F"_mesa.so.0.0.0" lib$F"_mesa.so.0"
| ln -sv lib$F"_mesa.so.0" lib$F"_mesa.so"
| done
|
| rm -v *amber*

re-built and installed the package, the problem has been solved.
Comment by Eduardo Escobar (eduardoeae) - Monday, 02 May 2022, 09:15 GMT
https://bbs.archlinux.org/viewtopic.php?pid=2031815#p2031815

Apparently libglvnd is missing amber in its database but you can force it by exporting:
__GLX_VENDOR_LIBRARY_NAME=amber

| option(
| 'amber',
| type : 'boolean',
| value : false,
| description : 'Configure LTS build to coexist with Mesa >= 22.0'
| )

The flag "amber=true" used in the PKGBUILD is meant for two different versions of mesa coexisting. Currently (in archlinux) mesa and mesa-amber conflict each other.
They should remove the flag or rebuild the packages to coexist adding a message at install about exporting that variable.
Comment by Martin Schnitkemper (Martin-MS) - Monday, 02 May 2022, 10:00 GMT
I re-built the package with the flag "amber=false" and also omitting the whole flag in an additional run, that results into

| libEGL.so.1.0.0
| libGL.so.1.2.0
| libGLESv2.so.2.0.0
| libvulkan_intel.so
| libvulkan_lvp.so
| libvulkan_radeon.so

and its symbolic links, but not a libEGL_mesa.so.0.0.0 or libGLX_mesa.so.0.0.0.

In result, the installation of the package fails due to conflicting files owned by libglvnd, i.e.

| mesa-amber: /usr/lib/libEGL.so exists in filesystem (owned by libglvnd)
| mesa-amber: /usr/lib/libEGL.so.1 exists in filesystem (owned by libglvnd)
| mesa-amber: /usr/lib/libGL.so exists in filesystem (owned by libglvnd)
| mesa-amber: /usr/lib/libGL.so.1 exists in filesystem (owned by libglvnd)

Where have I to add a missing "amber" in the "libglvnd"-database to try that solution?
Comment by Eduardo Escobar (eduardoeae) - Monday, 02 May 2022, 22:34 GMT
All the apps using GLX call to libGL.so. And usually this is glvnd sending all this calls to the different GLX libraries (libGLX_mesa.so if mesa, libGLX_nvidia.so if nvidia and supposedly libGLX_amber.so if mesa-amber; but this is what is not working as intended)

Changing glvnd=auto to "true" uses the system glvnd. Otherwise mesa builds without support for glvnd and all the others vendors, with libGL.so being straight mesa (the same library called libGLX_mesa.so if glvnd is present)

Changing vulkan-drivers=auto to "" disables the vulkan drivers (not supported by old hardware anyway) like repo's mesa-amber does.

"Where have I to add a missing "amber" in the "libglvnd"-database to try that solution?"
These rules seem to be in /usr/share/glvnd/egl_vendor.d/ for EGL but nowhere for GLX
Comment by Eduardo Escobar (eduardoeae) - Sunday, 08 May 2022, 23:16 GMT
This is fixed in mesa amber 21.3.8-5
Comment by Thomas Lübking (luebking) - Tuesday, 07 February 2023, 03:23 GMT
  • Field changed: Percent Complete (100% → 0%)
It's back again w/ 21.3.9-4(possibly all 21.3.9)
https://bbs.archlinux.org/viewtopic.php?pid=2083244#p2083244
Comment by Toolybird (Toolybird) - Tuesday, 07 February 2023, 03:23 GMT
So IIUC, the 32-bit version was never fixed.
Comment by Laurent Carlier (lordheavy) - Thursday, 16 February 2023, 18:32 GMT
please check with lib32-mesa-amber-21.3.9-5

Loading...