Created attachment 657762 [details] build.log, emerge.info, emerge.pqv After setting -J1 as make option stated in bug #739848 this happens: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib64/libGL.so: undefined reference to `_glapi_tls_Current' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:1538: cinelerra] Error 1 make[3]: Leaving directory '/var/tmp/portage/media-video/cinelerra-2.3-r1/work/CinelerraCV-2.3/cinelerra' make[2]: *** [Makefile:1899: all-recursive] Error 1 make[2]: Leaving directory '/var/tmp/portage/media-video/cinelerra-2.3-r1/work/CinelerraCV-2.3/cinelerra' make[1]: *** [Makefile:512: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/media-video/cinelerra-2.3-r1/work/CinelerraCV-2.3' make: *** [Makefile:442: all] Error 2 Could this be related to a missing rebuild dependency from libGL?
This happened after upgrading to media-libs/libglvnd-1.3.2 Could be here a missing dependency for deprecated version of libgl?
This error typically happen in larger world updates where: 1. transiting from eselect-opengl to libglvnd 2. using nvidia-drivers 3. something using OpenGL is rebuilt before nvidia-drivers is (this will happen to about any GL-using packages, cairo, qtgui, etc...) xorg-server is exempt from #3 due to using a workaround blocker, but everything else will fail.. and I don't think adding more blockers is a good idea. If the above match your situation, workaround is to: `emerge -1 nvidia-drivers mesa xorg-server` to finish the libglvnd transition then continue your world update. I don't think this issue (potentially affecting over 700 packages if taken separately) will ever be properly fixed, especially now that eselect-opengl is being removed.
(In reply to Ionen Wolkens from comment #2) > If the above match your situation, workaround is to: > `emerge -1 nvidia-drivers mesa xorg-server` > to finish the libglvnd transition then continue your world update. > Compiled after recompiling the ebuilds you mentioned. As I understand, didn't that mean that libglvnd should force a recompilation of those as a runtime dependency? Maybe this couldn't be catched by emerge since is a reverse dependency... In that context and if not already available, I suggest to have a documentation page about that like the one for gcc.
Comment on attachment 657762 [details] build.log, emerge.info, emerge.pqv Please attach plaintext as often as is possible.
Comment on attachment 657762 [details] build.log, emerge.info, emerge.pqv $ file file.tar.gz file.tar.gz: Zip archive data, at least v2.0 to extract :-(
*** Bug 739902 has been marked as a duplicate of this bug. ***
Seeing that bug #711780 is marked fixed, I suppose there is no general solution to this problem? Every package depending on a libGL provider has to fend for itself?
(In reply to Jeroen Roovers from comment #7) > Seeing that bug #711780 is marked fixed, I suppose there is no general > solution to this problem? Every package depending on a libGL provider has to > fend for itself? Workarounds could be made but what I'd qualify the "adequate" fix (relating to nvidia-drivers+libglvnd being a mesa alternative) is far too widespread. Given most people have already moved to libglvnd and eselect-opengl is soon to be removed, it may be a bit late for a solution to be worth it. This issue came up many times on IRC/forums, and we've just been helping people get through this 1-time issue they'll never see again. Probably still see it a few times from people updating old systems though. IMO individual packages like this should just close these bugs, not much to do about it unless someone comes up with a global workable solution.
Forgot to CC myself.
(In reply to Jeroen Roovers from comment #5) > Comment on attachment 657762 [details] > build.log, emerge.info, emerge.pqv > > $ file file.tar.gz > file.tar.gz: Zip archive data, at least v2.0 to extract > > :-( Sorry for that, I thought to be doing a good approach, since it was more than one file and attachment upload only allows one file. I will create individual files and upload them. Do you think that would be important to add those files now?
(In reply to Ionen Wolkens from comment #8) > > IMO individual packages like this should just close these bugs, not much to > do about it unless someone comes up with a global workable solution. Why not create a documentation page like the one for GCC to collect this cases and to remember later the procedure?
(In reply to Samuel Bernardo from comment #11) > Why not create a documentation page like the one for GCC to collect this > cases and to remember later the procedure? Solution or not, I think this bug is being left open (unlike the other one) so that people can find it by searching for the error and get informed, essentially accomplishing that. And providing files again isn't necessary, just keep it in mind for next time.
*** Bug 748411 has been marked as a duplicate of this bug. ***
I don't think this is possible anymore with libglvnd.
(In reply to Matt Turner from comment #14) > I don't think this is possible anymore with libglvnd. With yes, but the issue occur during migration. I still see occasional people run into this when they update old systems from earlier this year or more. But it has gotten a lot rarer, I don't believe many left that haven't migrated so I'd say it's fine to close.
