Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Xorg 1.16 → 1.17 updated with file collisions
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
mgorny
Developer
Developer


Joined: 27 Apr 2007
Posts: 80

PostPosted: Wed Dec 09, 2015 7:05 am    Post subject: Reply with quote

If you find some time, please paste the output of:

Code:
ldconfig -p | grep 'libGL\.so'


If it points to /usr/lib64/libGL.so, try:

Code:
ldconfig -X


and see if that changes it.
Back to top
View user's profile Send private message
orionbelt
Apprentice
Apprentice


Joined: 05 Apr 2006
Posts: 165
Location: Brussels, Belgium

PostPosted: Wed Dec 09, 2015 12:15 pm    Post subject: Reply with quote

Code:
# ldconfig -p | grep 'libGL\.so'
        libGL.so.1 (libc6,x86-64) => /usr/lib64/opengl/nvidia/lib/libGL.so.1
        libGL.so.1 (libc6,x86-64) => /usr/lib64/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib32/opengl/nvidia/lib/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib32/libGL.so.1
        libGL.so (libc6,x86-64) => /usr/lib64/opengl/nvidia/lib/libGL.so
        libGL.so (libc6,x86-64) => /usr/lib64/libGL.so
        libGL.so (libc6) => /usr/lib32/opengl/nvidia/lib/libGL.so
        libGL.so (libc6) => /usr/lib32/libGL.so

I am not sure what it means for the same .so to point to different paths... But ldconfig -X does not seem to change it:

Code:
# ldconfig -X
# ldconfig -p | grep 'libGL\.so'
        libGL.so.1 (libc6,x86-64) => /usr/lib64/opengl/nvidia/lib/libGL.so.1
        libGL.so.1 (libc6,x86-64) => /usr/lib64/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib32/opengl/nvidia/lib/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib32/libGL.so.1
        libGL.so (libc6,x86-64) => /usr/lib64/opengl/nvidia/lib/libGL.so
        libGL.so (libc6,x86-64) => /usr/lib64/libGL.so
        libGL.so (libc6) => /usr/lib32/opengl/nvidia/lib/libGL.so
        libGL.so (libc6) => /usr/lib32/libGL.so
Back to top
View user's profile Send private message
bookwood
Tux's lil' helper
Tux's lil' helper


Joined: 06 Oct 2005
Posts: 107
Location: Dortmund

PostPosted: Thu Dec 10, 2015 11:09 pm    Post subject: Reply with quote

My Nvidia Optimus also can not load following modules after my last update:
Code:

kwin(3176) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_magiclamp"  is not supported
kwin(3176) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_blur"  is not supported
kwin(3176) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_flipswitch"  is not supported
kwin(3176) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_startupfeedback"  is not supported
kwin(3176) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_cube"  is not supported
kwin(3176) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_cubeslide"  is not supported


All effects works fine since the update 1 week ago. When I switch from Xrender to any Opengl version I got:

Code:
Failed to activate desktop effects using the given configuration options. Settings will be reverted to their previous values.

Check your X configuration. You may also consider changing advanced options, especially changing the compositing type.


The last update seems to disable opengl on many nvidia cards. I recompile everythin with emerge -e but it does not help.
Code:

ldconfig -p | grep 'libGL\.so'
        libGL.so.1 (libc6,x86-64) => /usr/lib64/opengl/nvidia/lib/libGL.so.1
        libGL.so.1 (libc6,x86-64) => /usr/lib64/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib32/opengl/nvidia/lib/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib32/libGL.so.1
        libGL.so (libc6,x86-64) => /usr/lib64/opengl/nvidia/lib/libGL.so
        libGL.so (libc6,x86-64) => /usr/lib64/libGL.so
        libGL.so (libc6) => /usr/lib32/opengl/nvidia/lib/libGL.so
        libGL.so (libc6) => /usr/lib32/libGL.so


ldconfig -X change nothing. I can not use opengl anymore on my nvidia laptop :-(
My Dell Laptop with an intel card works fine.

Has anybody an idea which packets be masked to restore the opengl features?
Back to top
View user's profile Send private message
bensimons
n00b
n00b


Joined: 20 Feb 2014
Posts: 8

PostPosted: Wed Jan 13, 2016 3:19 am    Post subject: Reply with quote

Hi,

We've noticed the latest version of Mesa (11.0.6) clobbers the "libGL.so" links in /usr/lib*
I've tried to re-open a bug which seemed to refer to this: https://bugs.gentoo.org/show_bug.cgi?id=567200

here's the difference.
Code:
media-libs/mesa-10.3.7-r1 installs:
 $ equery f mesa|grep so|grep libGL
/usr/lib32/opengl/xorg-x11/lib/libGL.so
/usr/lib32/opengl/xorg-x11/lib/libGL.so.1
/usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2.0
/usr/lib64/opengl/xorg-x11/lib/libGL.so
/usr/lib64/opengl/xorg-x11/lib/libGL.so.1
/usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2.0

media-libs/mesa-11.0.6 installs (clobbers):
 $ equery f mesa|grep so|grep libGL
/usr/lib32/libGL.so
/usr/lib32/libGL.so.1
/usr/lib32/libGL.so.1.2.0
/usr/lib64/libGL.so
/usr/lib64/libGL.so.1
/usr/lib64/libGL.so.1.2.0

If you're using the nvidia-drivers, then /usr/lib64/libGL.so used to be a symbolic link:

Code:
libGL.so -> opengl/nvidia/lib/libGL.so.349.16

Once mesa-11.0.6 is installed, this link is clobbered and it becomes a library file:
Code:
lrwxrwxrwx 1 root root     14 Jan 11 16:08 /usr/lib64/libGL.so -> libGL.so.1.2.0
lrwxrwxrwx 1 root root     14 Jan 11 16:08 /usr/lib64/libGL.so.1 -> libGL.so.1.2.0
-rwxr-xr-x 1 root root 618920 Jan 11 16:07 /usr/lib64/libGL.so.1.2.0

At the moment it doesn't seem too easy to mask mesa-11.0.6 and roll back. I guess someone needs to review the ebuild files between 11.0.6 and 10.3.7-r1

b.
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 2509
Location: Canada

PostPosted: Wed Jan 13, 2016 7:04 am    Post subject: Reply with quote

I had similar collisions with build-in intel driver (can't vouch for exactly the same now, but they were coming from mesa). Was not so lucky with outcome.
Rebuild of xf86-video-intel-2.21.25 pizzly log

x11-drivers/xf86-video-intel-2.21.15::gentoo USE="dri sna udev xvmc -glamor -uxa"


no fails on configuration step with

Code:

checking for DRI1... yes
checking for dri.h... no
checking for sarea.h... no
checking for dristruct.h... no
checking whether to include DRI1 support... no
configure: error: DRI1 requested but prerequisites not found


what I see is that /usr/include/xorg/{dri.h,sarea.h,dristruct.h} form xorg-server-1.17.4 are happily present
Not sure about DRI1 request - all Xorg.logs I have should dri2 was always used at runtime
Back to top
View user's profile Send private message
bensimons
n00b
n00b


Joined: 20 Feb 2014
Posts: 8

PostPosted: Wed Jan 13, 2016 7:38 am    Post subject: Reply with quote

ah. Could be we had LD_LIBRARY_PATH set, which was overriding what ldconfig sets up in /etc/ld.so.conf, which in turn is updated by "env-update", which is run when you source /etc/profile. Unfortunately, it seems, the old-skool method of setting LD_LIBRARY_PATH breaks this. Clearing LD_LIBRARY_PATH returned everything to regular working order.

$ unset LD_LIBRARY_PATH
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum