On Sun, Aug 2, 2009 at 7:47 PM, Kevin O'Gorman<kogor...@gmail.com> wrote: > On Sun, Aug 2, 2009 at 7:27 AM, Arttu V.<arttu...@gmail.com> wrote: >> On 8/2/09, Kevin O'Gorman <kogor...@gmail.com> wrote: >>> checking for GL/glu.h... yes >>> checking for glVertex3d in -lGLcore... no >> >> Starting from here, libGLcore.so on my current desktop system belongs >> to nvidia-drivers: >> >> lrwxrwxrwx 1 root root 30 2.8. 17:13 /usr/lib64/libGLcore.so -> >> opengl/nvidia/lib/libGLcore.so >> >> If you are similarly running proprietary ati-drivers or >> nvidia-drivers, then you should probably re-emerge them, then run >> eselect opengl set (whatever you use). >> > > An interesting idea but no joy. > I re-emerged xf86-video-mach64 (for my motherboard's Rage XL). > I re-selected ati for opengl. > > I peeked at /usr/lib and got something that looks a little different from > yours: > treat lib # ls -l --color=n libGL* > -rw-r--r-- 1 root root 743 2009-08-01 20:52 libGLU.la > lrwxrwxrwx 1 root root 11 2009-08-01 20:52 libGLU.so -> libGLU.so.1 > lrwxrwxrwx 1 root root 20 2009-08-01 20:52 libGLU.so.1 -> > libGLU.so.1.3.070300 > -rwxr-xr-x 1 root root 456268 2009-08-01 20:52 libGLU.so.1.3.070300 > lrwxrwxrwx 1 root root 11 2009-08-01 20:52 libGLw.so -> libGLw.so.1 > lrwxrwxrwx 1 root root 15 2009-08-01 20:52 libGLw.so.1 -> libGLw.so.1.0.0 > -rwxr-xr-x 1 root root 10572 2009-08-01 20:52 libGLw.so.1.0.0 > treat lib # > > I attempted to re-emerge wxGTK and it finished in this way: > > > checking for GTK+ version... > checking for pkg-config... /usr/bin/pkg-config > checking for GTK+ - version >= 2.0.0... yes (version 2.14.7) > checking whether gtk_icon_size_lookup is declared... yes > checking if GTK+ is version >= 2.6... yes > checking for X11/Xlib.h... yes > checking for X11/XKBlib.h... yes > checking for sql.h... yes > checking for SQLAllocEnv in -liodbc... no > checking for SQLAllocEnv in -lunixodbc... no > checking for SQLAllocEnv in -lodbc... yes > checking for Xinerama... yes > checking for Xxf86vm extension... yes > checking for X11/extensions/xf86vmode.h... yes > checking for -lSM - X11 session management... yes > checking for OpenGL headers... found in /usr/include > checking for GL/gl.h... yes > checking GL/glu.h usability... yes > checking GL/glu.h presence... yes > checking for GL/glu.h... yes > checking for -lGL... no > checking for -lMesaGL... no > configure: error: OpenGL libraries not available > > !!! Please attach the following file when seeking support: > !!! > /var/tmp/portage/x11-libs/wxGTK-2.8.10.1-r1/work/wxPython-src-2.8.10.1/wxgtk_build/config.log > * > * ERROR: x11-libs/wxGTK-2.8.10.1-r1 failed. > * Call stack: > * ebuild.sh, line 49: Called src_configure > * environment, line 2800: Called econf > '--enable-compat26' '--enable-shared' '--enable-unicode' > '--with-regex=builtin' '--with-zlib=sys' '--with-expat=sys' > '--disable-debug' '--disable-precomp-headers' '--with-sdl' > '--with-odbc=sys' '--enable-graphics_ctx' '--enable-gui' > '--with-libpng=sys' '--with-libxpm=sys' '--with-libjpeg=sys' > '--with-libtiff=sys' '--enable-mediactrl' '--enable-opengl' > '--with-opengl' '--with-gnomeprint' '--without-gnomevfs' > * ebuild.sh, line 534: Called die > * The specific snippet of code: > * die "econf failed" > * The die message: > * econf failed > * > * If you need support, post the topmost build error, and the call > stack if relevant. > * A complete build log is located at > '/var/tmp/portage/x11-libs/wxGTK-2.8.10.1-r1/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/x11-libs/wxGTK-2.8.10.1-r1/temp/environment'. > * > >>>> Failed to emerge x11-libs/wxGTK-2.8.10.1-r1, Log file: > >>>> '/var/tmp/portage/x11-libs/wxGTK-2.8.10.1-r1/temp/build.log' > treat GL #
Even with this failure it was an interesting idea. So I switched to eselect opengl set xorg-x11 and now wxGTK gets past configuration and is building. I'll try the other holdout later, when this one finishes: openoffice. The questions now arise: 1) is something missing in mach64? It worked before the latest xorg re-org. 2) is the eselect option "ati" even correct? Is it an artifiact of the thrashing around I did with ati-drivers until I discovered that I needed to use mach64? If this is the case, why is there not an option for mach64? Inquiring minds want to know. ++ kevin
