Bugzilla Bug 293428

After update to x11-drivers/nvidia-drivers-190.42-r3,
x11-base/xorg-server-1.7.1 system is totally broken. revdep-rebuild dies on
error "/bin/grep: /usr/lib64/libGL.la: No such file or directory" because if we
believe http://gentoo-portage.com/x11-drivers/nvidia-drivers/ChangeLog 

"06 Nov 2009; Doug Goldstein <cardoe@gentoo.org>
+nvidia-drivers-190.42-r3.ebuild:
remove generation of libGL.la since eselect-opengl-1.0.9 and newer no
longer uses it. refactor installation of libraries to fix FreeBSD issues"

Solution is:

emerge dev-util/lafilefixer
lafilefixer --justfixit
revdep-rebuild

Please add this very important information in the section pkg_postinst () file
/ usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-190.42-r3.ebuild

Created an attachment (id=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.