Re: [gentoo-user] mesa build failure
On 27/11/2017 20:18, Walter Dnes wrote: > I'm running 32-bit Gentoo. mesa is the last remaining package in the > current emerge update. Just in case, I tried... > > MAKEOPTS="-j1" emerge --changed-use --deep --update @world > > That did not help. Attached are the build log and output of > > emerge --info '=media-libs/mesa-17.1.8::gentoo' > This is your build error: /var/tmp/portage/media-libs/mesa-17.1.8/work/mesa-17.1.8/src/mesa/swrast/s_aatritemp.h: In function 'rgba_aa_tri': /var/tmp/portage/media-libs/mesa-17.1.8/work/mesa-17.1.8/src/mesa/swrast/s_aatritemp.h:196:57: error: implicit declaration of function 'omp_get_thread_num' [-Werror=implicit-function-declaration] span.array = SWRAST_CONTEXT(ctx)->SpanArrays + omp_get_thread_num(); IIRC openmp provides that function. But his: cc1: some warnings being treated as errors make[5]: *** [Makefile:2946: swrast/s_aatriangle.lo] Error 1 make[5]: Leaving directory '/var/tmp/portage/media-libs/mesa-17.1.8/work/mesa-17.1.8-abi_x86_32.x86/src/mesa' mesa has 18 versions in-tree and mesa-17.1.8 is the second oldest. Any special reason you are stuck so far back? A package.mask you no longr actually need maybe? My first action would be to use something more rcent that functions for yu. Alan -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] mesa build failure
On Friday 26 June 2009 22:02:54 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? I haven't looked there yet but I will. I'm on a mission here. For this machine I want emerge -e @system to install NOTHING having to do with X11. After I get to that point, depclean'ed, revdep'ed, eix-test-obsoleted, then I'm going back to installing X from scratch. I've just gotten past the emerge -e @system part now. I'm sort of surprised the openssh shows up as part of @system, or it's getting pulled in somehow, and its default flags are dragging in X. USE=X pulls in x11-apps/xauth so you likely want to disable that flag. Sort of anal I suppose but these machine have been neglected for the last couple of years being stuck with old drivers old kernels. If I'm going to try and get the newest ati-drivers working I feel like I sort of owe it to those developers (and myself) to have as few issues hanging out as possible. Look at it this way: the only known factor that leads to easy-maintainable and sane systems for all is analness coming from the top :-) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. I will repeat the experiment this morning and post back info on the steps as I go along. I suppose I could copy Nikos on this thread directly to possibly catch his attention but I ll save that for later. Cheers, Mark Cheers, Mark
Re: [gentoo-user] mesa build failure
On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ #
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28 lib myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 8 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/include/ total 716 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. -rw-r--r-- 1 root root 90752 Jun 27 10:28 gl.h -rw-r--r-- 1 root root 461180 Jun 27 10:28 glext.h -rw-r--r-- 1 root root 17155 Jun 27 10:28 glx.h -rw-r--r-- 1 root root 34142 Jun 27 10:28 glxext.h -rw-r--r-- 1 root root 2453 Jun 27 10:20 glxmd.h -rw-r--r-- 1 root root 77887 Jun 27 10:20 glxproto.h -rw-r--r-- 1 root root 10613 Jun
Re: [gentoo-user] mesa build failure
Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28 lib myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 8 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/include/ total 716 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. -rw-r--r-- 1 root root 90752 Jun 27 10:28 gl.h -rw-r--r-- 1 root root 461180 Jun 27 10:28 glext.h -rw-r--r-- 1 root root
Re: [gentoo-user] mesa build failure
On Samstag 27 Juni 2009, Mark Knecht wrote: Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28 lib myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 8 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/include/ total 716 drwxr-xr-x 2 root root 4096 Jun 27 10:28 .
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 1:25 PM, Volker Armin Hemmannvolkerar...@googlemail.com wrote: On Samstag 27 Juni 2009, Mark Knecht wrote: Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28 lib myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 8 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. myth12 ~ # ls -al
Re: [gentoo-user] mesa build failure
On Samstag 27 Juni 2009, Mark Knecht wrote: On Sat, Jun 27, 2009 at 1:25 PM, Volker Armin Hemmannvolkerar...@googlemail.com wrote: On Samstag 27 Juni 2009, Mark Knecht wrote: Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 2:00 PM, Volker Armin Hemmannvolkerar...@googlemail.com wrote: On Samstag 27 Juni 2009, Mark Knecht wrote: On Sat, Jun 27, 2009 at 1:25 PM, Volker Armin Hemmannvolkerar...@googlemail.com wrote: On Samstag 27 Juni 2009, Mark Knecht wrote: Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 10:16 AM, Mark Knechtmarkkne...@gmail.com wrote: As part of emerge @world mesa isn't building. It complains (I think) about a missing GL/glxproto.h file. Anyone know where this file is supposed to come from? x11-proto/glproto perhaps
Re: [gentoo-user] mesa build failure
On Friday 26 June 2009 17:16:26 Mark Knecht wrote: Hi, As part of emerge @world mesa isn't building. It complains (I think) about a missing GL/glxproto.h file. Anyone know where this file is supposed to come from? x11-proto/glproto a...@nazgul ~/.ssh $ locate glxproto.h /usr/lib64/opengl/xorg-x11/include/glxproto.h /usr/include/GL/glxproto.h a...@nazgul ~/.ssh $ equery belongs /usr/lib64/opengl/xorg- x11/include/glxproto.h * Searching for /usr/lib64/opengl/xorg-x11/include/glxproto.h ... x11-proto/glproto-1.4.10 (/usr/lib64/opengl/xorg-x11/include/glxproto.h) (The second file in the locate output is a symlink to the first) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 8:24 AM, Alan McKinnonalan.mckin...@gmail.com wrote:
On Friday 26 June 2009 17:16:26 Mark Knecht wrote:
Hi,
As part of emerge @world mesa isn't building. It complains (I
think) about a missing GL/glxproto.h file.
Anyone know where this file is supposed to come from?
x11-proto/glproto
a...@nazgul ~/.ssh $ locate glxproto.h
/usr/lib64/opengl/xorg-x11/include/glxproto.h
/usr/include/GL/glxproto.h
a...@nazgul ~/.ssh $ equery belongs /usr/lib64/opengl/xorg-
x11/include/glxproto.h
* Searching for /usr/lib64/opengl/xorg-x11/include/glxproto.h ...
x11-proto/glproto-1.4.10 (/usr/lib64/opengl/xorg-x11/include/glxproto.h)
(The second file in the locate output is a symlink to the first)
--
alan dot mckinnon at gmail dot com
Interesting. Thanks guys.
so is this a mistake in the ebuild? Why isn't it picking it up automatically?
I seemed to already have the package installed:
myth12 ~ # emerge -pv -1 glproto
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] x11-proto/glproto-1.4.9 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB
myth12 ~ #
Looks like there's some other problem. Look at the end of me trying to
reinstall it:
Emerging (1 of 1) x11-proto/glproto-1.4.9
* glproto-1.4.9.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...
[ ok ]
* checking ebuild checksums ;-) ...
[ ok ]
* checking auxfile checksums ;-) ...
[ ok ]
* checking miscfile checksums ;-) ...
[ ok ]
Unpacking source...
Unpacking glproto-1.4.9.tar.bz2 to
/var/tmp/portage/x11-proto/glproto-1.4.9/work
Source unpacked in /var/tmp/portage/x11-proto/glproto-1.4.9/work
Compiling source in
/var/tmp/portage/x11-proto/glproto-1.4.9/work/glproto-1.4.9 ...
./configure --prefix=/usr --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --prefix=/usr --datadir=/usr/share
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating glproto.pc
make -j2
make: Nothing to be done for `all'.
Source compiled.
Test phase [not enabled]: x11-proto/glproto-1.4.9
Install glproto-1.4.9 into /var/tmp/portage/x11-proto/glproto-1.4.9/image/
category x11-proto
make[1]: Entering directory
`/var/tmp/portage/x11-proto/glproto-1.4.9/work/glproto-1.4.9'
make[1]: Nothing to be done for `install-exec-am'.
test -z /usr/include/GL || /bin/mkdir -p
/var/tmp/portage/x11-proto/glproto-1.4.9/image//usr/include/GL
/usr/bin/install -c -m 644 'glxint.h'
'/var/tmp/portage/x11-proto/glproto-1.4.9/image//usr/include/GL/glxint.h'
/usr/bin/install -c -m 644 'glxmd.h'
'/var/tmp/portage/x11-proto/glproto-1.4.9/image//usr/include/GL/glxmd.h'
/usr/bin/install -c -m 644 'glxproto.h'
'/var/tmp/portage/x11-proto/glproto-1.4.9/image//usr/include/GL/glxproto.h'
/usr/bin/install -c -m 644 'glxtokens.h'
'/var/tmp/portage/x11-proto/glproto-1.4.9/image//usr/include/GL/glxtokens.h'
test -z /usr/include/GL/internal || /bin/mkdir -p
/var/tmp/portage/x11-proto/glproto-1.4.9/image//usr/include/GL/internal
/usr/bin/install -c -m 644 'glcore.h'
'/var/tmp/portage/x11-proto/glproto-1.4.9/image//usr/include/GL/internal/glcore.h'
test -z /usr/lib/pkgconfig || /bin/mkdir -p
/var/tmp/portage/x11-proto/glproto-1.4.9/image//usr/lib/pkgconfig
/usr/bin/install -c -m 644 'glproto.pc'
'/var/tmp/portage/x11-proto/glproto-1.4.9/image//usr/lib/pkgconfig/glproto.pc'
make[1]: Leaving directory
`/var/tmp/portage/x11-proto/glproto-1.4.9/work/glproto-1.4.9'
* Moving GL files for dynamic switching ...
[ ok ]
Completed installing glproto-1.4.9 into
/var/tmp/portage/x11-proto/glproto-1.4.9/image/
Installing (1 of 1) x11-proto/glproto-1.4.9
Switching to xorg-x11 OpenGL interface...ln: creating symbolic link
`./libglx.so': File exists
!!! Error: Failed to create /lib/libglx.so
/var/tmp/portage/x11-proto/glproto-1.4.9/temp/environment: line 3218:
17432 Killed eselect opengl set --use-old
${OPENGL_DIR}
Auto-cleaning packages...
No outdated packages were found on your system.
* GNU info directory index is up-to-date.
myth12 ~ #
the glxproto.h file does exist:
myth12 ~ # slocate glxproto
/usr/include/GL/glxproto.h
/usr/lib/opengl/xorg-x11/include/glxproto.h
myth12 ~ #
How do I fix this issue with it complaining about the link?
the mesa emerge is still failing the same way:
i686-pc-linux-gnu-gcc -c -I. -I../../../include
-I../../../include/GL/internal -I../../../src/mesa
-I../../../src/mesa/glapi -I/usr/include/drm -O2 -march=i686
-fomit-frame-pointer -pipe
Re: [gentoo-user] mesa build failure
On Friday 26 June 2009 18:04:07 Mark Knecht wrote: On Fri, Jun 26, 2009 at 8:24 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 17:16:26 Mark Knecht wrote: Hi, As part of emerge @world mesa isn't building. It complains (I think) about a missing GL/glxproto.h file. Anyone know where this file is supposed to come from? x11-proto/glproto a...@nazgul ~/.ssh $ locate glxproto.h /usr/lib64/opengl/xorg-x11/include/glxproto.h /usr/include/GL/glxproto.h a...@nazgul ~/.ssh $ equery belongs /usr/lib64/opengl/xorg- x11/include/glxproto.h * Searching for /usr/lib64/opengl/xorg-x11/include/glxproto.h ... x11-proto/glproto-1.4.10 (/usr/lib64/opengl/xorg-x11/include/glxproto.h) (The second file in the locate output is a symlink to the first) -- alan dot mckinnon at gmail dot com Interesting. Thanks guys. so is this a mistake in the ebuild? Why isn't it picking it up automatically? I seemed to already have the package installed: myth12 ~ # emerge -pv -1 glproto These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-proto/glproto-1.4.9 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB myth12 ~ # Have you done the usual things with opengl: emerge mesa revdepr-rebuild eselect opengl ? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 9:17 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 18:04:07 Mark Knecht wrote: On Fri, Jun 26, 2009 at 8:24 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 17:16:26 Mark Knecht wrote: Hi, As part of emerge @world mesa isn't building. It complains (I think) about a missing GL/glxproto.h file. Anyone know where this file is supposed to come from? x11-proto/glproto a...@nazgul ~/.ssh $ locate glxproto.h /usr/lib64/opengl/xorg-x11/include/glxproto.h /usr/include/GL/glxproto.h a...@nazgul ~/.ssh $ equery belongs /usr/lib64/opengl/xorg- x11/include/glxproto.h * Searching for /usr/lib64/opengl/xorg-x11/include/glxproto.h ... x11-proto/glproto-1.4.10 (/usr/lib64/opengl/xorg-x11/include/glxproto.h) (The second file in the locate output is a symlink to the first) -- alan dot mckinnon at gmail dot com Interesting. Thanks guys. so is this a mistake in the ebuild? Why isn't it picking it up automatically? I seemed to already have the package installed: myth12 ~ # emerge -pv -1 glproto These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-proto/glproto-1.4.9 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB myth12 ~ # Have you done the usual things with opengl: emerge mesa revdepr-rebuild eselect opengl ? Yep. did all those earlier and saw this OpenGL problem with eselect. Sort of disregarded it at the time and figured it would get worked out later but now it's in the way. I'm trying a kernel rebuild and will reinstall modules, reboot, etc. Strange issue. - Mark
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 11:04 AM, Mark Knechtmarkkne...@gmail.com wrote: so is this a mistake in the ebuild? Why isn't it picking it up automatically? I seemed to already have the package installed: What is your eselect opengl set to? Maybe try setting it to xorg-x11 if it's not already, then emerge mesa, then change it back to your other driver afterward.
Re: [gentoo-user] mesa build failure
On Friday 26 June 2009 18:43:37 Mark Knecht wrote: Yep. did all those earlier and saw this OpenGL problem with eselect. Sort of disregarded it at the time and figured it would get worked out later but now it's in the way. So what exactly did eselect say at the time? Therein likely lies the solution to your problem. I'm trying a kernel rebuild and will reinstall modules, reboot, etc. What do you hope to achieve with that? OpenGL runs in user-space, and you have a problem with a missing header file - totally unrelated to the kernle and it's modules. Strange issue. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 10:57 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 18:43:37 Mark Knecht wrote: Yep. did all those earlier and saw this OpenGL problem with eselect. Sort of disregarded it at the time and figured it would get worked out later but now it's in the way. So what exactly did eselect say at the time? Therein likely lies the solution to your problem. Well, at the time it seems I remember two options for eselect list opengl, but at this point I'm seeing only 1. Anyway, trying to set it to 1 causes the same error message I remember: myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create lib/libglx.so Killed myth12 ~ # myth12 ~ # slocate libglx /usr/lib/opengl/xorg-x11/extensions/libglx.so /usr/lib/xorg/modules/extensions/libglx.so myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/libglx.so -rwxr-xr-x 1 root root 338584 Jun 23 16:41 /usr/lib/opengl/xorg-x11/extensions/libglx.so myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 344 drwxr-xr-x 2 root root 4096 Jun 23 16:42 . drwxr-xr-x 5 root root 4096 Jun 23 16:42 .. -rwxr-xr-x 1 root root 338584 Jun 23 16:41 libglx.so myth12 ~ # myth12 ~ # equery belongs /usr/lib/opengl/xorg-x11/extensions/libglx.so [ Searching for file(s) /usr/lib/opengl/xorg-x11/extensions/libglx.so in *... ] x11-base/xorg-server-1.5.3-r6 (/usr/lib/opengl/xorg-x11/extensions/libglx.so) myth12 ~ # So the file is there and owned by xorg-server which is in the list to get rebuilt. I'm trying a kernel rebuild and will reinstall modules, reboot, etc. What do you hope to achieve with that? OpenGL runs in user-space, and you have a problem with a missing header file - totally unrelated to the kernle and it's modules. I made a mistake earlier when I built this new kernel. (Updating from 2.6.19 to 2.6.29) I forgot to include ext2 support in the kernel so for a little while I had newer modules than the kernel because I couldn't mount the boot directory to install the kernel. I decide this morning to rebuild the whole kernel, rewrite the modules and get the whole thing consistent. Nothing more than cleaning up an earlier mistake. I've just rebuilt python and run python-updater just to make sure that I didn't miss rebuilding something that was required. I have no issues at all completely removing xorg-server and everything it loads and rebuilding it from scratch if folks think that might help. thanks, Mark
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 11:23 AM, Mark Knechtmarkkne...@gmail.com wrote: On Fri, Jun 26, 2009 at 10:57 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 18:43:37 Mark Knecht wrote: Yep. did all those earlier and saw this OpenGL problem with eselect. Sort of disregarded it at the time and figured it would get worked out later but now it's in the way. So what exactly did eselect say at the time? Therein likely lies the solution to your problem. Well, at the time it seems I remember two options for eselect list opengl, but at this point I'm seeing only 1. Anyway, trying to set it to 1 causes the same error message I remember: myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create lib/libglx.so Killed myth12 ~ # myth12 ~ # slocate libglx /usr/lib/opengl/xorg-x11/extensions/libglx.so /usr/lib/xorg/modules/extensions/libglx.so myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/libglx.so -rwxr-xr-x 1 root root 338584 Jun 23 16:41 /usr/lib/opengl/xorg-x11/extensions/libglx.so myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 344 drwxr-xr-x 2 root root 4096 Jun 23 16:42 . drwxr-xr-x 5 root root 4096 Jun 23 16:42 .. -rwxr-xr-x 1 root root 338584 Jun 23 16:41 libglx.so myth12 ~ # myth12 ~ # equery belongs /usr/lib/opengl/xorg-x11/extensions/libglx.so [ Searching for file(s) /usr/lib/opengl/xorg-x11/extensions/libglx.so in *... ] x11-base/xorg-server-1.5.3-r6 (/usr/lib/opengl/xorg-x11/extensions/libglx.so) myth12 ~ # So the file is there and owned by xorg-server which is in the list to get rebuilt. I'm trying a kernel rebuild and will reinstall modules, reboot, etc. What do you hope to achieve with that? OpenGL runs in user-space, and you have a problem with a missing header file - totally unrelated to the kernle and it's modules. I made a mistake earlier when I built this new kernel. (Updating from 2.6.19 to 2.6.29) I forgot to include ext2 support in the kernel so for a little while I had newer modules than the kernel because I couldn't mount the boot directory to install the kernel. I decide this morning to rebuild the whole kernel, rewrite the modules and get the whole thing consistent. Nothing more than cleaning up an earlier mistake. I've just rebuilt python and run python-updater just to make sure that I didn't miss rebuilding something that was required. I have no issues at all completely removing xorg-server and everything it loads and rebuilding it from scratch if folks think that might help. thanks, Mark Humm...removing xorg-server allowed me to set OpenGL to xorg-x11 without an error: myth12 ~ # emerge -C xorg-server x11-base/xorg-server selected: 1.5.3-r6 protected: none omitted: none 'Selected' packages are slated for removal. 'Protected' and 'omitted' packages will not be removed. Waiting 5 seconds before starting... (Control-C to abort)... Unmerging in: 5 4 3 2 1 Unmerging x11-base/xorg-server-1.5.3-r6... * GNU info directory index is up-to-date. myth12 ~ # updatedb myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ ls: cannot access /usr/lib/opengl/xorg-x11/extensions/: No such file or directory myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # and now mesa seems to be building. Problem solved - sort of. ;-) Cheers, Mark
Re: [gentoo-user] mesa build failure
On Friday 26 June 2009 20:23:31 Mark Knecht wrote: On Fri, Jun 26, 2009 at 10:57 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 18:43:37 Mark Knecht wrote: Yep. did all those earlier and saw this OpenGL problem with eselect. Sort of disregarded it at the time and figured it would get worked out later but now it's in the way. So what exactly did eselect say at the time? Therein likely lies the solution to your problem. Well, at the time it seems I remember two options for eselect list opengl, but at this point I'm seeing only 1. Anyway, trying to set it to 1 causes the same error message I remember: myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists OK, I think this is your clue. /usr/lib64/xorg/modules/extensions/libglx.so is merely a symlink. eselect opengl creates it by linking to the openGL implementation you choose - mesa/nvidia/whatever. I think you had a regular file there, put there by Xorg and eselect can overwrite it with a symlink. Are you upgrading from an ancient xorg? !!! Error: Failed to create lib/libglx.so Killed myth12 ~ # myth12 ~ # slocate libglx /usr/lib/opengl/xorg-x11/extensions/libglx.so /usr/lib/xorg/modules/extensions/libglx.so myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/libglx.so -rwxr-xr-x 1 root root 338584 Jun 23 16:41 /usr/lib/opengl/xorg-x11/extensions/libglx.so myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 344 drwxr-xr-x 2 root root 4096 Jun 23 16:42 . drwxr-xr-x 5 root root 4096 Jun 23 16:42 .. -rwxr-xr-x 1 root root 338584 Jun 23 16:41 libglx.so myth12 ~ # Yes, that is what happened. So the emerge -C xorg-server; emerge -av xorg- server you mention later is probably the correct approach. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 11:31 AM, Mark Knechtmarkkne...@gmail.com wrote:
On Fri, Jun 26, 2009 at 11:23 AM, Mark Knechtmarkkne...@gmail.com wrote:
On Fri, Jun 26, 2009 at 10:57 AM, Alan McKinnonalan.mckin...@gmail.com
wrote:
On Friday 26 June 2009 18:43:37 Mark Knecht wrote:
Yep. did all those earlier and saw this OpenGL problem with eselect.
Sort of disregarded it at the time and figured it would get worked out
later but now it's in the way.
So what exactly did eselect say at the time?
Therein likely lies the solution to your problem.
Well, at the time it seems I remember two options for eselect list
opengl, but at this point I'm seeing only 1. Anyway, trying to set it
to 1 causes the same error message I remember:
myth12 ~ # eselect opengl list
Available OpenGL implementations:
[1] xorg-x11
myth12 ~ # eselect opengl set 1
Switching to xorg-x11 OpenGL interface...ln: creating symbolic link
`./libglx.so': File exists
!!! Error: Failed to create lib/libglx.so
Killed
myth12 ~ #
myth12 ~ # slocate libglx
/usr/lib/opengl/xorg-x11/extensions/libglx.so
/usr/lib/xorg/modules/extensions/libglx.so
myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/libglx.so
-rwxr-xr-x 1 root root 338584 Jun 23 16:41
/usr/lib/opengl/xorg-x11/extensions/libglx.so
myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/
total 344
drwxr-xr-x 2 root root 4096 Jun 23 16:42 .
drwxr-xr-x 5 root root 4096 Jun 23 16:42 ..
-rwxr-xr-x 1 root root 338584 Jun 23 16:41 libglx.so
myth12 ~ #
myth12 ~ # equery belongs /usr/lib/opengl/xorg-x11/extensions/libglx.so
[ Searching for file(s) /usr/lib/opengl/xorg-x11/extensions/libglx.so in
*... ]
x11-base/xorg-server-1.5.3-r6 (/usr/lib/opengl/xorg-x11/extensions/libglx.so)
myth12 ~ #
So the file is there and owned by xorg-server which is in the list to
get rebuilt.
I'm trying a kernel rebuild and will reinstall modules, reboot, etc.
What do you hope to achieve with that? OpenGL runs in user-space, and you
have
a problem with a missing header file - totally unrelated to the kernle and
it's modules.
I made a mistake earlier when I built this new kernel. (Updating from
2.6.19 to 2.6.29) I forgot to include ext2 support in the kernel so
for a little while I had newer modules than the kernel because I
couldn't mount the boot directory to install the kernel. I decide this
morning to rebuild the whole kernel, rewrite the modules and get the
whole thing consistent. Nothing more than cleaning up an earlier
mistake.
I've just rebuilt python and run python-updater just to make sure that
I didn't miss rebuilding something that was required.
I have no issues at all completely removing xorg-server and everything
it loads and rebuilding it from scratch if folks think that might
help.
thanks,
Mark
Humm...removing xorg-server allowed me to set OpenGL to xorg-x11
without an error:
myth12 ~ # emerge -C xorg-server
x11-base/xorg-server
selected: 1.5.3-r6
protected: none
omitted: none
'Selected' packages are slated for removal.
'Protected' and 'omitted' packages will not be removed.
Waiting 5 seconds before starting...
(Control-C to abort)...
Unmerging in: 5 4 3 2 1
Unmerging x11-base/xorg-server-1.5.3-r6...
* GNU info directory index is up-to-date.
myth12 ~ # updatedb
myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/
ls: cannot access /usr/lib/opengl/xorg-x11/extensions/: No such file
or directory
myth12 ~ # eselect opengl list
Available OpenGL implementations:
[1] xorg-x11
myth12 ~ # eselect opengl set 1
Switching to xorg-x11 OpenGL interface... done
myth12 ~ #
and now mesa seems to be building.
Problem solved - sort of. ;-)
Cheers,
Mark
So the weirdness continues. mesa built but then xorg-server failed
with the same failure:
Installing (4 of 11) x11-base/xorg-server-1.5.3-r6
* SetUID: [chmod go-r] /usr/bin/Xorg ...
[ ok ]
Switching to xorg-x11 OpenGL interface...ln: creating symbolic link
`./libglx.so': File exists
!!! Error: Failed to create /lib/libglx.so
/var/tmp/portage/x11-base/xorg-server-1.5.3-r6/temp/environment: line
3403: 32139 Killed eselect opengl set ${OLD_IMPLEM}
* Users of reduced blanking now need:
*Option ReducedBlanking
* In the relevant Monitor section(s).
* Make sure your reduced blanking modelines are safe!
* You must rebuild all drivers if upgrading from xorg-server 1.4.1
* or earlier, because the ABI changed. If you cannot start X because
* of module version mismatch errors, this is your problem.
* You can generate a list of all installed packages in the x11-drivers
* category using this command:
* emerge portage-utils; qlist -I -C x11-drivers/
- Mark
Re: [gentoo-user] mesa build failure
On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? I haven't looked there yet but I will. I'm on a mission here. For this machine I want emerge -e @system to install NOTHING having to do with X11. After I get to that point, depclean'ed, revdep'ed, eix-test-obsoleted, then I'm going back to installing X from scratch. I've just gotten past the emerge -e @system part now. I'm sort of surprised the openssh shows up as part of @system, or it's getting pulled in somehow, and its default flags are dragging in X. Sort of anal I suppose but these machine have been neglected for the last couple of years being stuck with old drivers old kernels. If I'm going to try and get the newest ati-drivers working I feel like I sort of owe it to those developers (and myself) to have as few issues hanging out as possible. Thanks, Mark
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 Cheers, Mark
