[ubuntu-x] [libgl1-mesa-dev] mesa libGL.so link should not put in /usr/lib/x86_64-linux-gnu

Wed Dec 4 09:53:08 UTC 2013

I don't really get what you mean by "Before installation my program run
with libraries put in the rpath which is mesa libGL.so (as it is in a
standard folder).".
To me that sounds as if you have an application and that it will be run
before it gets even installed... Out of my head I could only think of one
situation when that would happen and that is directly after an application
has been built to run unit tests. If this is the case, then I think this is
what you actually want. For unit tests I highly recommend to always use
Mesa's software rendering as this ensures that your application can run
unit tests even on build machines with varying graphics hardware.

If I'm wrong with my guess please clarify. ;-)

On Wed, Dec 4, 2013 at 8:41 AM, kajo keji <kajokeji.2013 at gmail.com> wrote:

> Thank you again Michael for your long answer. It becomes clearer for me.
> It remains one difficult point about how to handle this with cmake (that
> uses rpath).
> Before installation my program run with libraries put in the rpath which
> is mesa libGL.so (as it is in a standard folder)
> NB: after installation, all become well as the rpath is removed.
>
>
> 2013/12/3 Michael Schaller <misch at google.com>
>
>> Usually programs link against a less specific library name unless they
>> have to be more specific.
>> So most programs that use OpenGL are linked against libGL.so.1 and not
>> against libGL.so.1.# or something even more (vendor-)specific.
>>
>> Usually this hierarchy of less specific library names to more specific
>> library names is done via symlinks.
>> On my Ubuntu x86_64 installation it looks like this:
>> $ ls -l /usr/lib/x86_64-linux-gnu/mesa/libGL.so*
>> lrwxrwxrwx 1 root root     12 Nov 18 09:56
>> /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 -> libGL.so.1.2
>> -rw-r--r-- 1 root root 390352 Nov 18 09:57
>> /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2
>>
>> $ ls -la /usr/lib/nvidia-current/libGL.so*
>> lrwxrwxrwx 1 root root      10 Nov  8 18:51
>> /usr/lib/nvidia-current/libGL.so -> libGL.so.1
>> lrwxrwxrwx 1 root root      15 Nov  8 18:51
>> /usr/lib/nvidia-current/libGL.so.1 -> libGL.so.331.20
>> -rw-r--r-- 1 root root 1144680 Nov  8 18:52
>> /usr/lib/nvidia-current/libGL.so.321.20
>>
>> You can find out which library a program would load with the help of ldd:
>> $ ldd /usr/bin/glxgears | grep libGL
>>  libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1
>>
>> It also looks to me that libGL.so isn't used usually. Mesa doesn't ship
>> one on my installation. So I wouldn't look too much on libGL.so but rather
>> check that libGL.so.1 is correctly set.
>> Other than that I can't give much advice as the LD configuration is
>> distribution specific and is heavily influenced by symlinks,
>> /etc/ld.so.conf and /etc/ld.so.conf.d/. These can be altered with every
>> installation and graphics drivers tend to meddle with them. Also usually
>> one doesn't touch these symlinks or the LD config unless he/she knows what
>> they are doing and if there are manual changes in place it can be that they
>> could be overwritten by package updates...
>> That said if you would remove/reinstall the fglrx or nvidia package then
>> most likely it would reconfigure this to a sane state for you. ;-)
>>
>>
>> On Tue, Dec 3, 2013 at 10:07 AM, kajo keji <kajokeji.2013 at gmail.com>wrote:
>>
>>> Thank you Michael for your answer
>>> As for you, my libGL.so.1 link to the proprietary lib :
>>>         libGL.so.1 (libc6,x86-64) => /usr/lib/fglrx/libGL.so.1
>>>         libGL.so.1 (libc6) => /usr/lib32/fglrx/libGL.so.1
>>>
>>>         libGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so
>>>         libGL.so (libc6,x86-64) => /usr/lib/fglrx/libGL.so
>>>
>>> So libGL.so.1 seems to be used instead of libGL.so, here is the magic
>>> for me. I am a bit lost about how shared library names are handled...
>>>
>>>
>>> 2013/12/3 Michael Schaller <misch at google.com>
>>>
>>>> Kajo, it depends on your LD config.
>>>> On my Ubuntu x86_64 with binary NVIDIA driver it looks like this:
>>>>
>>>> $ ldconfig -p | grep libGL.so.1
>>>> libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia-current/libGL.so.1
>>>>  libGL.so.1 (libc6) => /usr/lib32/nvidia-current/libGL.so.1
>>>>
>>>> $ cat /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf
>>>> /usr/lib/nvidia-current
>>>> /usr/lib32/nvidia-current
>>>>
>>>> As you can see with /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf in place
>>>> Mesa's libGL.so.1 is completely disabled.
>>>>
>>>>
>>>> On Tue, Dec 3, 2013 at 9:03 AM, kajo keji <kajokeji.2013 at gmail.com>wrote:
>>>>
>>>>> Thank you for your answer Maarten.
>>>>> You right !! After some clean up of my links and sudo ldconfig,
>>>>> everything are good. I just don't know how program select the good library
>>>>> at runtime as in my ld cache the mesa's comes first (ldconfig -p) :
>>>>>         libGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so
>>>>>         libGL.so (libc6,x86-64) => /usr/lib/fglrx/libGL.so
>>>>>
>>>>>
>>>>> 2013/12/2 Maarten Lankhorst <maarten.lankhorst at canonical.com>
>>>>>
>>>>>> op 02-12-13 14:29, kajo keji schreef:
>>>>>> > I suppose that is the aim of x86_64-linux-gnu_gl_conf alternative
>>>>>> to manage
>>>>>> > the link towards mesa, fglrx or nvidia lib, isn't it ?
>>>>>> > The same for i386-linux-gnu_gl_conf.
>>>>>> The abi is fixed and libGL.so is only used for linking. It doesn't
>>>>>> matter that applications link against mesa, they will still use the correct
>>>>>> library at runtime.
>>>>>>
>>>>>> ~Maarten
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ubuntu-x mailing list
>>>>> Ubuntu-x at lists.ubuntu.com
>>>>> Modify settings or unsubscribe at:
>>>>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-x/attachments/20131204/e15ce1e3/attachment-0001.html>