Summary: | gentoo is totally broken after update to x11-drivers/nvidia-drivers-190.42-r3 "requires /usr/lib64/libGL.la" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrey Ovcharov <sudormrfhalt> |
Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED CANTFIX | ||
Severity: | critical | CC: | bane.tsk, jeisom, kkrizka, tonglebeak, whereami, zioalex |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | revdep-rebuild log with error |
Description
Andrey Ovcharov
2009-11-16 21:35:39 UTC
Created attachment 210442 [details]
revdep-rebuild log with error
I believe this is INVALID: such note is already in eselect-opengl-1.1.1-r2. Why is it acceptable to leave the system broken? Why doesn't eselect-opengl symlink the .la? Or maybe run lafilefixer itself? Or maybe the opengl ebuilds should run it? Maybe that message should be printed by eselect-opengl when it changes the link? pkg_postinst messages are too easy to miss.. I didn't figure this out without searching for this bug. (In reply to comment #3) > Why is it acceptable to leave the system broken? Why doesn't eselect-opengl > symlink the .la? Or maybe run lafilefixer itself? Or maybe the opengl ebuilds > should run it? > > Maybe that message should be printed by eselect-opengl when it changes the > link? pkg_postinst messages are too easy to miss.. I didn't figure this out > without searching for this bug. > eselect-opengl can not make a symlink to libGL.la because this file does not exist after installing nvidia-drivers-190.42-r3 To learn what threatens to install nvidia-drivers-190.42-r3 where you need to say. The removal of .la files is very much on purpose. And like running revdep-rebuild for changes in .so versions portage is not aware that things may be broken. What the hell? Plenty of configure scripts are explicitly looking for /usr/lib64/libGL.la -- including xorg-server! It's totally irresponsible to leave things in this state. (In reply to comment #6) > What the hell? Plenty of configure scripts are explicitly looking for > /usr/lib64/libGL.la -- including xorg-server! Name a single one - no, xorg-server is a miss, it checks for the lib, not la file. (In reply to comment #7) > (In reply to comment #6) > > What the hell? Plenty of configure scripts are explicitly looking for > > /usr/lib64/libGL.la -- including xorg-server! > > Name a single one - no, xorg-server is a miss, it checks for the lib, > not la file. > Hi, media-libs/sdl-net-1.2.7 does. /bin/sh ./libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=nocona -O2 -pipe -fomit-frame-pointer -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Wl,-O1 -o libSDL_net.la -rpath /usr/lib64 -no-undefined -release 1.2 -version-info 0:7:0 SDLnet.lo SDLnetTCP.lo SDLnetUDP.lo SDLnetselect.lo -lSDL -lpthread grep: /usr/lib64/libGL.la: No such file or directory /bin/sed: can't read /usr/lib64/libGL.la: No such file or directory libtool: link: `/usr/lib64/libGL.la' is not a valid libtool archive make: *** [libSDL_net.la] Error 1 (In reply to comment #6) > What the hell? Plenty of configure scripts are explicitly looking for > /usr/lib64/libGL.la -- including xorg-server! > > It's totally irresponsible to leave things in this state. > Confirm that, many ebuild's need libGL.la (for example goffice) /bin/grep: /usr/lib64/libGL.la: No such file or directory /usr/bin/sed: can't read /usr/lib64/libGL.la: No such file or directory libtool: link: `/usr/lib64/libGL.la' is not a valid libtool archive When trying to emerge pango. So I have to run lafilefixer correct? @comment 9:no, that again a miss, it needs libSDL, libGL.la comes from one of the dependent la files. @comment 10: bugzilla not a support forum and (once again) the post-install message in eselect-opengl already tells that (In reply to comment #11) > @comment 9:no, that again a miss, it needs libSDL, > libGL.la comes from one of the dependent la files. > > @comment 10: bugzilla not a support forum > and (once again) the post-install message in > eselect-opengl already tells that > Excuse me, I came in to state that a certain package (pango) failed because of this bug. I said "I need to run lafilefixer right?" so that I could just _workaround_ the problem for the time being. I don't understand why you completely failed to ignore the fact that I was stating that pango failed to emerge due to a missing libgl.la. I'm well aware that this isn't a support forum. forums.gentoo.org if I cared enough to cry about this on there, but instead I came here instead to let you know that pango failed to emerge due to the missing libGL.la file. Please don't ignore my report, and also don't belittle me. That is all. Thanks. lafilefixer is't the solution i do not know exactly why, but some ebuild want libGL.la (goffice, abiword-plugins, etc) (In reply to comment #13) > lafilefixer is't the solution > i do not know exactly why, but some ebuild want libGL.la > (goffice, abiword-plugins, etc) > according to the post-merge messages from eselect-opengl lafilefixer *is* the solution. I can confirm `lafilefixer --justfixit` solved the issue where revdep-rebuild failed while trying to rebuild packages needing libGL.la. libdrm from the X11 overlay (which I needed to test the new nouveau driver for nvidia cards) also failed over missing /usr/lib64/libGL.la. Running the fixer solved the problem for me as well. emerge dev-util/lafilefixer lafilefixer --justfixit revdep-rebuild Fixed for me too. Without it I would still be getting failed builds all over the place. To add to this: All I did to encounter this was add ~amd64 to /etc/portage/package.keyword and emerge nvidia-drivers. I did not see and relevant post install message. From here I decided that I wanted to run the latest software and placed ACCEPT_KEYWORD="~amd64" in /etc/make.conf. Having done this I ran: emerge --update --newuse --deep --ask world - everyting blew up. I ran in to more build requiring libGL.la than 'just one or two. I was able to get most compiled by continuously using --skipfirst but in the end I found this bug and applied the suggested fix and bamb! fixed. To say this is not a bug or something that you can wash your hands from is, well, irresponsible. IMHO. This also breaks media-video/vlc /bin/grep: /usr/lib64/libGL.la: No such file or directory /bin/sed: can't read /usr/lib64/libGL.la: No such file or directory libtool: link: `/usr/lib64/libGL.la' is not a valid libtool archive make[4]: *** [libaout_sdl_plugin.la] Error 1 make[4]: Leaving directory `/var/tmp/portage/media-video/vlc-1.0.4/work/vlc-1.0.4/modules/audio_output' make[3]: *** [all] Error 2 make[3]: Leaving directory `/var/tmp/portage/media-video/vlc-1.0.4/work/vlc-1.0.4/modules/audio_output' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/media-video/vlc-1.0.4/work/vlc-1.0.4/modules' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/media-video/vlc-1.0.4/work/vlc-1.0.4' make: *** [all] Error 2 "lafilefixer --justfixit" may fix this case. However the large problem is after any package that installs a .la file may/probably need(s) fixed. lafilefixer need to be run on any .la file before/during the merging into the system by portage. IMHO lafilefixer --justfixit isn't fixing lot of stuff. Been trying to update a friends computer and envice is won't compile cause it keeps looking for: grep: /usr/lib64/libGL.la: No such file or directory /usr/bin/sed: can't read /usr/lib64/libGL.la: No such file or directory libtool: link: `/usr/lib64/libGL.la' is not a valid libtool archive make[3]: *** [libsmclient.la] Error 1 make[3]: Leaving directory `/var/tmp/portage/app-text/evince-2.26.2/work/evince-2.26.2/cut-n-paste/smclient' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-text/evince-2.26.2/work/evince-2.26.2/cut-n-paste' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-text/evince-2.26.2/work/evince-2.26.2' make: *** [all] Error 2 * ERROR: app-text/evince-2.26.2 failed: * compile failure Have ran lafilefixer --justfixit many times and no help. Also libglademm and a few others weren't emerging. So made a symlink /usr/lib64/libGL.la -> /usr/lib64/opengl/xorg-x11/lib/libGL.la and everything starts compiling. Hate to do that, but getting tired of running revdep-rebuild and having it keep failing and regular emerges failing trying to update. At least this works until something gets fixed. Hmm, lafilefixer, never seen it used to just specify the file, so did this: lafilefixer /usr/lib64/opengl/xorg-x11/lib/libGL.la /usr/lib64/opengl/xorg-x11/lib/libGL.la: Updating... Maybe that will work. It wasn't doing it before, but maybe that will do it. (In reply to comment #11) > @comment 9:no, that again a miss, it needs libSDL, > libGL.la comes from one of the dependent la files. > > @comment 10: bugzilla not a support forum > and (once again) the post-install message in > eselect-opengl already tells that FYI, this bug just happened to me. It's a bug because: 1. I checked "eselect news read all|egrep lafile", and it output nothing. 2. It failed to build media-libs/xine-lib-1.1.17:1. Now, when #1 is solved, it can be considered a support issue. Until then, undocumented things requiring google to find solution in a bug report forum is a bug. This happened while building target "system". Why I have to do revdep-rebuild in the middle of building target "system", I don't know. revdep-rebuild's going to pull in all sorts of crap from "world" and "everything" that I'm not concerned with in "system" building stage! > This happened while building target "system". Why I have to do revdep-rebuild
> in the middle of building target "system", I don't know. revdep-rebuild's
> going to pull in all sorts of crap from "world" and "everything" that I'm not
> concerned with in "system" building stage!
Followup: the revdep-rebuild step didn't seem necessary. xine-lib installed fine. revdep-rebuild will be done later.
|