Bug 701118 – app-text/sigil: cannot find libGL

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description jan vereecke 2019-11-24 23:44:13 UTC]

On a system with nouveau and nvidia both installed, sigil only works if either the nouveau driver is in use, or if the nvidia driver is in use with mesa uninstalled.
System tries to find libGL.so and always finds the mesa version.

Reproducible: Always

Steps to Reproduce:
1. Install a system with VIDEO_CARDS="nvidia nouveau"
2. eselect opengl nvidia
3. start xorg and ensure nvidia-drivers is active.
4. emerge sigil
5. to be certain: env-update && . /etc/profile
4. sigil
   ==> console gives an error message:
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Debug: Error creating openGL context

Actual Results:  
sigil cannot find libGL.so at /usr/lib64/opengl/nvidia/lib/libGL.so. (instead it tries to open the mesa version /usr/lib/libGL.so).
This is due to the /usr/bin/sigil, which is a script that manipulates LD_LIBRARY_PATH:

QTLIB_DIR="/usr/lib64"
SIGIL_BIN_DIR="/usr/lib64/sigil"
if [ -z "$LD_LIBRARY_PATH" ]; then
  LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$QTLIB_DIR"

since QTLIB_DIR is also the directory where the mesa libGL is contained, it is always selected before 

Expected Results:  
sigil starts and finds the correct nvidia libGL version:
possible solutions:
1. change /usr/bin/sigil script and explicitly add a path to nvidia libGL before QTLIB_DIR.NVIDIA_LIBGL="/usr/lib64/opengl/nvidia/lib"
QTLIB_DIR="/usr/lib64"
SIGIL_BIN_DIR="/usr/lib64/sigil"
if [ -z "$LD_LIBRARY_PATH" ]; then
  LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$NVIDIA_LIBGL:$QTLIB_DIR"

2. place mesa libGL.so in its own separate directory, and let /usr/lib64/libGL.so be a symlink to the correct version (symlink set by eselect)

3. don't use the script in the .desktop file and run the true sigil executable /usr/lib64/sigil/sigil

[Comment 1 Jonas Stein 2019-11-25 23:16:42 UTC]

It is sad to read that you have problems with the software. The situation seems to be a bit more complicate and requires some analysis.
We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. 

I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3].
I hope you understand, that I will close the bug here therefore and wish you good luck on one of the mentioned channels [4].
Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product.

When you do so, please add the exact category and package name with versions, you refer to. Please paste the emerge info as described on
https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket

[1] https://www.gentoo.org/get-involved/irc-channels/
[2] https://forums.gentoo.org/
[3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html
[4] https://www.gentoo.org/support/

[Comment 2 segmentation fault 2021-03-16 23:03:10 UTC]

(In reply to Jonas Stein from comment #1)
> It is sad to read that you have problems with the software. The situation
> seems to be a bit more complicate and requires some analysis.

There is nothing to analyze here. The report is ultra-clear and offers three alternatives for the solution. And yes, this *has* to do rather with Gentoo than with "upstream", because "upstream" is trying to mess with LD_LIBRARY_PATH, while Gentoo does not need such interventions to run the software in question - actually, messing with LD_LIBRARY_PATH breaks sigil in Gentoo.

I had the exact same problem as described in the bug report. I want to thank the original poster for the solutions - I wouldn't have solved it without his help.

I just commented the lines

if [ -z "$LD_LIBRARY_PATH" ]; then
  LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$QTLIB_DIR"
else
  LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$QTLIB_DIR:$LD_LIBRARY_PATH"
fi

and

export LD_LIBRARY_PATH

in /usr/bin/sigil and all is well now.

Gentoo users don't need sigil's "tricks" to use the right OpenGL library, as they can do:

eselect opengl list

which in my case gives:

Available OpenGL implementations:
  [1]   nvidia *
  [2]   xorg-x11

I strongly suggest patching /usr/bin/sigil to comment the above lines in the post-install phase of the ebuild. So this is Gentoo-related (and thus an ebuild issue) after all.

[Comment 3 Ionen Wolkens 2021-03-17 05:15:47 UTC]

(In reply to segmentation fault from comment #2)
> Gentoo users don't need sigil's "tricks" to use the right OpenGL library, as
> they can do:
> 
> eselect opengl list
?

eselect-opengl is gone, and so are nvidia's compat libraries with current drivers, i.e. /usr/lib64/opengl/nvidia/lib is gone

How old is that system?

[Comment 4 Ionen Wolkens 2021-03-17 05:38:51 UTC]

And from a quick try, sigil works fine with libglvnd and nvidia-drivers.

Original report sounds valid (being from 2019), but with current layout it's obsolete as /usr/lib64/libGL.so.1 (from libglvnd) is always correct regardless of mesa or nvidia-drivers.

Please update your system.

[Comment 5 segmentation fault 2021-03-17 13:37:50 UTC]

(In reply to Ionen Wolkens from comment #3)

> How old is that system?

Not very old, by my measures:

emerge --info | grep Timestamp

Timestamp of repository gentoo: Mon, 11 May 2020 00:45:01 +0000

You guys, you are going too fast. :-)))

[Comment 6 Sam James 2021-03-17 19:54:24 UTC]

(In reply to segmentation fault from comment #5)
> (In reply to Ionen Wolkens from comment #3)
> 
> > How old is that system?
> 
> Not very old, by my measures:
> 
> emerge --info | grep Timestamp
> 
> Timestamp of repository gentoo: Mon, 11 May 2020 00:45:01 +0000
> 
> You guys, you are going too fast. :-)))

.. not syncing and updating for a year is kind of not recommended.