mesa and xorg-server on 10.4

[michaelt@…]

Below is a sample of the output when trying to install the GtkGLExt port on OS X 10.5.1.

Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gtkglext/work/gtkglext-1.2.0" && ./configure --prefix=/opt/local " returned error 1
Command output: checking gdk/gdkscreen.h presence... yes
checking for gdk/gdkscreen.h... yes
checking for gdk_display_get_default in GDK library... yes
configure: GDK supports multihead
checking for gdk_x11_colormap_foreign_new... yes
checking for X... libraries /usr/X11/lib, headers /usr/X11/include
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for X11/Xmu/StdCmap.h... yes
checking for Xmu/StdCmap.h... no
checking for XmuLookupStandardColormap in -lXmu... yes
checking GL/glx.h usability... yes
checking GL/glx.h presence... yes
checking for GL/glx.h... yes
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
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 glVertex3d in -lGLcore... no
checking for glVertex3d in -lGL... no
checking for glVertex3f in -lGL... no
checking for glVertex3i in -lGL... no
checking for glVertex3s in -lGL... no
checking for glVertex3d in -lMesaGL... no
configure: error: Cannot find GL library

Error: The following dependencies failed to build: gtkglext
Error: Status 1 encountered during processing.

[michaelt@…]

I received this response from a guy on the XQuartz>X11-user group

Probable cause of the error: An infamous bug (or "improvement" according to Apple) in /usr/bin/ld that prevents linking to >/usr/X11/lib/libGL.dylib without extra contortions. See <​http://developer.apple.com/qa/qa2007/qa1567.html>

After taking a look at my config.log file this appears to be the problem. I am not sure how to fix it but just thought you'd all like to know.

[gjznituv@…]

I had the same problem. The first diff in #13624, and only it, solved the problem for me: attachment:ticket:13624:Portfile-gtkglext.diff​

[rowue@…]

see #13624

[jasper@…]

[44848] seems to have reintroduced this bug. I get the same output as the original reporter. Removing the two flag appends added in that changeset and replacing them with the flag in the diff above was the only way i could get this port to install.

[rowue@…]

I've added an variant "system_x11" to the gwyddion Portfile, so people with tiger can use the 3D features of gwyddion again - for the other variants I've removed the gtkglext-dependency.

Since this is more an nug in the interplay with gwyddion and gtkglext and x-windows, I've added jeremy hu to the cc (perhaps he have some suggestions)

[jeremyhu (Jeremy Huddleston Sequoia)]

If there is a bug, that is just a hack rather than the solution. You should be able to just have gtkglext and --with-gl regardless of what GL you are using. Update gwyddion with this patch. If there is still a problem, then it's a gtkglext bug (and should be fixed rather than hacking something together in a single dependent port). I'll take a look at gtkglext now...:

Index: Portfile
===================================================================
--- Portfile	(revision 47218)
+++ Portfile	(working copy)
@@ -25,40 +25,16 @@
 
 depends_lib         port:gtk2 \
                     port:libxml2 \
-                    port:fftw-3
+                    port:fftw-3 \
+                    port:gtkglext
 
-configure.args      --disable-desktop-file-update --without-gl
+configure.args      --disable-desktop-file-update
 
-if {![variant_isset system_x11]} {
-    configure.cflags-append     "-I${x11prefix}/include"
-    configure.ldflags-append    "-L${x11prefix}/lib"
+if { ![file exists ${prefix}/lib/pkgconfig/gl.pc] } {
+	configure.cppflags-append   -I${x11prefix}/include
+	configure.ldflags-append    -L${x11prefix}/lib
 }
 
-if {[variant_isset system_x11]} {
-    default_variants    +system_x11
-}
-
-
-# deactivation because of gtkglext problems
-# platform darwin 9 {
-#     if {[variant_isset system_x11]} {
-#         set darwin_9_glpath   /System/Library/Frameworks/OpenGL.framework/Versions/
-#         configure.ldflags-append -Wl,-dylib_file,${darwin_9_glpath}/A/Libraries/libGL.dylib:\
-#         ${darwin_9_glpath}/A/Libraries/libGL.dylib
-#     }
-# }
-
-platform darwin 8 {
-    if {[variant_isset system_x11]} {
-        depends_lib-append      port:gtkglext
-        configure.args-delete  --without-gl
-    }
-}
-
-variant system_x11 description {Using system X11 libraries} {
-    # dummy
-}
-
 post-activate {
         system "${prefix}/bin/update-mime-database ${prefix}/share/mime ; true"
 }

[rowue@…]

I know, this was an BUH (Big Ugly Hack) - that was the reason for me to cc you ;) I'll check things out on 10.4 and 10.5 now (will take some hours) and will inform you (and anybody interested in this ticket) afterwards

thanks for fast help ;)

[rowue@…]

glxinfo output on 10.4 after plugging in mesa

[rowue@…]

crash on 10.4 without installing mesa

[rowue@…]

Log after installing mesa

[rowue@…]

configure on 10.5 (without mesa)

[rowue@…]

The patch only works on 10.4/10.5 after plugging in mesa before (10.4 crashes ("localhost"), 10.5 doesn't configure) after plugging in mesa, gwyddion on 10.5 works as expected, gwyddion on 10.4 has no 3d view (feature) (see atachments)

[jeremyhu (Jeremy Huddleston Sequoia)]

I just finished working with George to backport the new HW rendering libGL to work on Tiger, and it's now in MacPorts. mesa should now be pulled in as a port: dependency across the tree (and obeys the +system_x11 variant if you want the old one on the system)... so libGL should not be a corner case library any more for X11.

My suggestion is to try again with the new mesa and gtkglext installed

[jeremyhu (Jeremy Huddleston Sequoia)]

Updated patch (adds comment and the configure.args-append:

Index: Portfile
===================================================================
--- Portfile	(revision 47261)
+++ Portfile	(working copy)
@@ -25,40 +25,20 @@
 
 depends_lib         port:gtk2 \
                     port:libxml2 \
-                    port:fftw-3
+                    port:fftw-3 \
+                    port:gtkglext
 
-configure.args      --disable-desktop-file-update --without-gl
+configure.args      --disable-desktop-file-update
 
-if {![variant_isset system_x11]} {
-    configure.cflags-append     "-I${x11prefix}/include"
-    configure.ldflags-append    "-L${x11prefix}/lib"
+if { ![file exists ${prefix}/lib/pkgconfig/gl.pc] } {
+        # AC_X_PATH blindly asks xmkmf where X11 is, and it always uses /usr/X11R6.
+        # These next three lines should cause AC_X_PATH to let us setup our CPPFLAGS
+        # and LDFLAGS without interference
+        configure.args-append --x-include=${prefix}/include --x-lib=${prefix}/lib
+        configure.cppflags-append -I${x11prefix}/include
+        configure.ldflags-append  -L${x11prefix}/lib
 }
 
-if {[variant_isset system_x11]} {
-    default_variants    +system_x11
-}
-
-
-# deactivation because of gtkglext problems
-# platform darwin 9 {
-#     if {[variant_isset system_x11]} {
-#         set darwin_9_glpath   /System/Library/Frameworks/OpenGL.framework/Versions/
-#         configure.ldflags-append -Wl,-dylib_file,${darwin_9_glpath}/A/Libraries/libGL.dylib:\
-#         ${darwin_9_glpath}/A/Libraries/libGL.dylib
-#     }
-# }
-
-platform darwin 8 {
-    if {[variant_isset system_x11]} {
-        depends_lib-append      port:gtkglext
-        configure.args-delete  --without-gl
-    }
-}
-
-variant system_x11 description {Using system X11 libraries} {
-    # dummy
-}
-
 post-activate {
         system "${prefix}/bin/update-mime-database ${prefix}/share/mime ; true"
 }

[rowue@…]

Checking mesa on OS X give now the following compile-error:

--->  Installing xorg-libXext @1.0.5_0
--->  Activating xorg-libXext @1.0.5_0
--->  Cleaning xorg-libXext
--->  Removing build directory for xorg-libXext
--->  Building mesa
Making sources for darwin
make[2]: Nothing to be done for `default'.
(cd drivers && make)
/bin/sh ../../../../bin/mklib -o OSMesa -linker 'gcc' -ldflags '' \
        -major 7 -minor 2 -patch 0 \
        -install ../../../../lib  \
        -id /opt/local/lib/libOSMesa.7.dylib \
        -L../../../../lib -lGL osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a
mklib: Making Darwin shared library:  libOSMesa.7.2.dylib
mklib: Installing libOSMesa.7.2.dylib libOSMesa.7.dylib libOSMesa.dylib in ../../../../lib
make[4]: `../../../lib/libGLU.dylib' is up to date.
Making programs for darwin
tclsh8.5 gen_code.tcl
make: tclsh8.5: Command not found
make: *** [apple_xgl_api.h] Error 127
Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_Users_rowue_macports_dports_x11_mesa/work/Mesa-7.2/../AppleSGLX-52 && make builds/libGL.1.2.dylib INSTALL_DIR=/opt/local X11_DIR=/usr/X11R6 LDFLAGS='-L/opt/local/lib' CFLAGS='-I/opt/local/include -O2' INSTALL_DIR='/opt/local'" returned error 2
Command output: tclsh8.5 gen_code.tcl
make: tclsh8.5: Command not found
make: *** [apple_xgl_api.h] Error 127

Warning: the following items did not execute (for mesa): org.macports.activate org.macports.build org.macports.destroot org.macports.install
Error: Status 1 encountered during processing.

[rowue@…]

After plugging in "tcl", compiling mesa works, installation in broken:

--->  Activating mesa @7.2_5+hw_render
Error: Target org.macports.activate returned: Image error: /opt/local/include/GL/glxint.h is being used by the active xorg-glproto port.  Please deactivate this port first, or use the -f flag to force the activation.
Warning: the following items did not execute (for mesa): org.macports.activate
Error: Status 1 encountered during processing.

[rowue@…]

Forced install:

bratapfel:~ rowue$ sudo port -v -f install mesa
--->  Installing mesa @7.2_5+hw_render
--->  Activating mesa @7.2_5+hw_render
Warning: File /opt/local/include/GL/glxint.h already exists.  Moving to: /opt/local/include/GL/glxint.h.mp_1235478902.
Warning: File /opt/local/include/GL/glxmd.h already exists.  Moving to: /opt/local/include/GL/glxmd.h.mp_1235478902.
Warning: File /opt/local/include/GL/glxproto.h already exists.  Moving to: /opt/local/include/GL/glxproto.h.mp_1235478902.
--->  Cleaning mesa
--->  Removing build directory for mesa

[rowue@…]

PS: OS X means 10.4 at this point, can check 10.5 this evening (has switch os ;)

[rowue@…]

10.4.: compile (works with issues above), gwyddion crashes:

fallobst:~/Desktop/IOS rowue$ /opt/local/bin/gwyddion
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
_X11TransSocketUNIXConnect: Cannot connect to non-local host Statusbar::shadow_type = 0
}
wid
XIO:  fatal IO error 22 (Unknown error: 0) on X server ":0.0"
      after 90 requests (89 known processed) with 16 events remaining.
fallobst:~/Desktop/IOS rowue$ 

[jeremyhu (Jeremy Huddleston Sequoia)]

Sorry for the mesa/glproto conflict... I'm taking care of it now...

The extension warnings are just informative and expected.

The _X11TransSocketUNIXConnect is interesting...

What is the output of:

cd /opt/local/lib
for f in *dylib; do otool -L $f | grep -q /usr/X11 && echo $f; done

cd /opt/local/bin
for f in *; do otool -L $f | grep -q /usr/X11 && echo $f; done

[jeremyhu (Jeremy Huddleston Sequoia)]

mesa is fixed in r47289 (fixed the conflicts... if you did -f you're fine... the conflict files are identical (modulo comments).

For the tiger crash, run this (repasted for formatting):

cd /opt/local/lib
for f in *dylib; do otool -L $f | grep -q /usr/X11 && echo $f; done

cd /opt/local/bin
for f in *; do otool -L $f | grep -q /usr/X11 && echo $f; done

[rowue@…]

output for *dylib (/opt/local/lib):

libGL.1.2.dylib
libGL.1.dylib
libGL.dylib

output for * (/opt/local/bin): empty

(had done -f during compile)

[jeremyhu (Jeremy Huddleston Sequoia)]

rowue: what's the output for:

otool -L /opt/local/lib/libGL.dylib?

You should get something like this:

libGL.dylib:
	/opt/local/lib/libGL.1.2.dylib (compatibility version 1.2.0, current version 1.2.0)
	/usr/lib/libXplugin.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)

What is it linking to in /usr/X11? Can you provide a build log for your mesa build?

[jeremyhu (Jeremy Huddleston Sequoia)]

If you fix up the linking to properly link against the macports libX11 and libXext, I expect the _X11TransSocketUNIXConnect issue will go away...

[rowue@…]

Replying to jeremyhu@…:

rowue: what's the output for:

otool -L /opt/local/lib/libGL.dylib?

You should get something like this:

libGL.dylib:
	[...]

What is it linking to in /usr/X11? Can you provide a build log for your mesa build?

Two people - one thought: just updated und cleared my ports to provide you with this information - will take a while ;)

regs

Rolf

[rowue@…]

Buildlog for mesa on 10.4 - Timestamp is GMT

[rowue@…]

Buildlog for mesa attached

[rowue@…]

"otool -L $f | grep -q /usr/X11" on /opt/local/lib was empty in this stage

[jeremyhu (Jeremy Huddleston Sequoia)]

And how does gwiddyon behave now?

[rowue@…]

Replying to jeremyhu@…:

And how does gwiddyon behave now?

Compiling mesa seperate before gwyddion gives empty "otool" - gwyddion starts, but got no openGL. (seperate means "port uninstall -f installed; port install mesa; port install gwyddion") If I compile mesa within gwyddion ("port uninstall -f installed; port install gwyddion") gwyddion crashes again. (perhaps the seperate issue will only compile "mesa" and not "mesa +hw_render")

Besides the both libs you mentioned (libXext, libX11), there is also an link against libXplugin)

[rowue@…]

I added

--- .svn/text-base/Portfile.svn-base    2009-02-25 10:35:22.000000000 +0100
+++ Portfile    2009-02-25 20:22:34.000000000 +0100
@@ -1,4 +1,4 @@
-# $Id$
+# $Id: Portfile 47289 2009-02-25 02:08:09Z jeremyhu@macports.org $
 
 PortSystem          1.0
 
@@ -61,6 +61,7 @@
 if { ![file exists /usr/include/Xplugin.h] } {
         # Xplugin.h is missing on Tiger
         configure.cppflags-append -I${filespath}/include
+               configure.ldflags-append  -L${x11prefix}/lib
 }
 
 if {! [variant_isset system_x11]} {

the /usr/X11 links went away ...

give a try now

[jeremyhu (Jeremy Huddleston Sequoia)]

uhm... that's not consistent. Adding -L${x11prefix}/lib to ldflags should not cause it to NOT link with the X11libs.

You shouldn't be doing that dflags append in the check for Xplugin.h. It's done in the check for gl.pc in the patch I sent you above.

[jeremyhu (Jeremy Huddleston Sequoia)]

I dunno how to use gwidyon, but with my patch, it links fine:

/opt/local/bin/gwyddion:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.17.0)
	/opt/local/lib/libgwyapp2.0.dylib (compatibility version 5.0.0, current version 5.1.0)
	/opt/local/lib/libgwymodule2.0.dylib (compatibility version 2.0.0, current version 2.1.0)
	/opt/local/lib/libgwydgets2.0.dylib (compatibility version 7.0.0, current version 7.2.0)
	/opt/local/lib/libgtkglext-x11-1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libgdkglext-x11-1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libGLU.1.dylib (compatibility version 1.3.0, current version 1.3.0)
	/opt/local/lib/libGL.1.2.dylib (compatibility version 1.2.0, current version 1.2.0)
	/opt/local/lib/libXmu.6.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libpangox-1.0.0.dylib (compatibility version 2204.0.0, current version 2204.1.0)
	/opt/local/lib/libgwydraw2.0.dylib (compatibility version 1.0.0, current version 1.2.0)
	/opt/local/lib/libgtk-x11-2.0.0.dylib (compatibility version 1401.0.0, current version 1401.7.0)
	/opt/local/lib/libgdk-x11-2.0.0.dylib (compatibility version 1401.0.0, current version 1401.7.0)
	/opt/local/lib/libatk-1.0.0.dylib (compatibility version 2410.0.0, current version 2410.1.0)
	/opt/local/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 1401.0.0, current version 1401.7.0)
	/opt/local/lib/libgio-2.0.0.dylib (compatibility version 1801.0.0, current version 1801.3.0)
	/opt/local/lib/libtiff.3.dylib (compatibility version 12.0.0, current version 12.2.0)
	/opt/local/lib/libjasper.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0)
	/opt/local/lib/libpangocairo-1.0.0.dylib (compatibility version 2204.0.0, current version 2204.1.0)
	/opt/local/lib/libcairo.2.dylib (compatibility version 10803.0.0, current version 10803.6.0)
	/opt/local/lib/libpangoft2-1.0.0.dylib (compatibility version 2204.0.0, current version 2204.1.0)
	/opt/local/lib/libpixman-1.0.dylib (compatibility version 15.0.0, current version 15.0.0)
	/opt/local/lib/libpng12.0.dylib (compatibility version 35.0.0, current version 35.0.0)
	/opt/local/lib/libXrender.1.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libpango-1.0.0.dylib (compatibility version 2204.0.0, current version 2204.1.0)
	/opt/local/lib/libfontconfig.1.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 7.2.0)
	/opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.19.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
	/opt/local/lib/libgmodule-2.0.0.dylib (compatibility version 1801.0.0, current version 1801.3.0)
	/opt/local/lib/libgwyprocess2.0.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libfftw3.3.dylib (compatibility version 6.0.0, current version 6.3.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)
	/opt/local/lib/libgwyddion2.0.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libgobject-2.0.0.dylib (compatibility version 1801.0.0, current version 1801.3.0)
	/opt/local/lib/libglib-2.0.0.dylib (compatibility version 1801.0.0, current version 1801.3.0)
	/opt/local/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0)
	/opt/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

[rowue@…]

The Binary is ok - the Problem is in /opt/local/lib!

The Libraries:

• libGL.1.2.dylib
• libGL.1.dylib
• libGL.dylib

got some links to /usr/X11 ...

I put in the LDflags section above to the mesa Portfile and the links from the Libraries went away - I'm just compiling now

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, well there is something wrong there...

Do you understand what I mean... ADDING -L/usr/X11/lib to LDFLAGS should not cause you to NOT link against /usr/X11/lib libraries. Please revert to what is in svn for the mesa Portfile. What you have in your mesa build log above is correct:

gcc -Wall -ggdb3 -Os -DPTHREADS -D_REENTRANT -DPUBLIC=""  -I/opt/local/include -O2 -o builds/libGL.1.2.dylib -dynamiclib -install_name /opt/local/lib/libGL.1.2.dylib -compatibility_version 1.2 -current_version 1.2 -lXplugin -framework ApplicationServices -framework CoreFoundation -L/opt/local/lib -L/opt/local/lib -Wl,-single_module -lXext -lX11 -Wl,-exported_symbols_list,exports.list glxext.o glxcmds.o glx_pbuffer.o glx_query.o glxcurrent.o glxextensions.o appledri.o apple_glx_context.o apple_glx.o pixel.o compsize.o apple_visual.o apple_cgl.o glxreply.o glcontextmodes.o apple_xgl_api.o apple_glx_drawable.o xfont.o apple_glx_pbuffer.o apple_glx_pixmap.o apple_xgl_api_read.o glx_empty.o glx_error.o

there is no reference to /usr/X11 there whatsoever (and there SHOULDN'T be!)

Further, you told me that after installing, you didn't have any links against /usr/X11/* ... so I'm confused about what you did to bring in the /usr/X11 links. Since this is *just* wrt mesa, please try to isolate it in mesa and checking 'otool -L /opt/local/lib/libGL.dylib' rather than testing gwiddyon

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to rowue@…:

Replying to jeremyhu@…:

And how does gwiddyon behave now?

Compiling mesa seperate before gwyddion gives empty "otool" - gwyddion starts, but got no openGL. (seperate means "port uninstall -f installed; port install mesa; port install gwyddion") If I compile mesa within gwyddion ("port uninstall -f installed; port install gwyddion") gwyddion crashes again. (perhaps the seperate issue will only compile "mesa" and not "mesa +hw_render")

the build log you attached was for +hw_render

There should be no difference between "separate" and "together".

Besides the both libs you mentioned (libXext, libX11), there is also an link against libXplugin)

As it should for the HW renderer.

[rowue@…]

port installed after configuring gtkglext

[rowue@…]

otool -L *dylib after configuring gtkglext

[rowue@…]

installing mesa directly gives the right linking (as seen in the mesa logs), installing mesa in the run of "port configure gtkglext" gives the wrong linking (as can be seen in gtkglext_otool.200902261200.log.

The build protocol can be fetched from:

​https://bone.digitalis.org/gtkglext_configure.200902261200.log

reg's,

Rolf

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, you're linking with -L/usr/X11R6/lib

gcc -Wall -ggdb3 -Os -DPTHREADS -D_REENTRANT -DPUBLIC=""  -I/opt/local/include -O2 -o builds/libGL.1.2.dylib -dynamiclib -install_name /opt/local/lib/libGL.1.2.dylib -compatibility_version 1.2 -current_version 1.2 -lXplugin -framework ApplicationServices -framework CoreFoundation -L/usr/X11R6/lib -L/opt/local/lib -Wl,-single_module -lXext -lX11 -Wl,-exported_symbols_list,exports.list glxext.o glxcmds.o glx_pbuffer.o glx_query.o glxcurrent.o glxextensions.o appledri.o apple_glx_context.o apple_glx.o pixel.o compsize.o apple_visual.o apple_cgl.o glxreply.o glcontextmodes.o apple_xgl_api.o apple_glx_drawable.o xfont.o apple_glx_pbuffer.o apple_glx_pixmap.o apple_xgl_api_read.o glx_empty.o glx_error.o

It looks like you built with your patch above that added -L/usr/X11R6/lib to the LDFLAGS. Remove it and try again.

[jeremyhu (Jeremy Huddleston Sequoia)]

Actually... another possibility is that X11_DIR is being set to $x11prefix which happens based on:

	if {! [file exists ${prefix}/lib/libX11.dylib]} {
		build.args-append X11_DIR=${x11prefix}
		destroot.args-append X11_DIR=${x11prefix}	
	}

so do you not have /opt/local/lib/libX11.dylib for some reason? Did you have +system_x11 variant set at some point?

[rowue@…]

• I've removed the patch - as you told me ;)
• No variant system_x11 set - neither on CL or in variants.conf

I take an look on /opt/local/lib/libX11.dylib later (at home in one hour) (Perhaps an log of "first mesa, than gtkglext" can be interesting)

[jeremyhu (Jeremy Huddleston Sequoia)]

do a debug log (that just includes mesa... limit the spam)

[rowue@…]

clean ports, Output of port -d build mesa

[rowue@…]

clean ports, partial (mesa only) output of "port -d build gtkglext"

[rowue@…]

uninstalled mesa after build o gtkglext - output of "port -d install mesa"

[rowue@…]

• Installing mesa alone (mesa_build_only.200902270114.log) - linking ok
• Installing mesa during gtkglext (gtkglext_build_snap_mesa.200902270114.log) - linking wrong
• removing and cleaning mesa after building gtkglext and reinstall (gtkglext_mesa_build.200902270114.log) - linking ok

Complete build of gtkglext can be downloaded from ​https://bone.digitalis.org/mesa/gtkglext_build.200902270114.log

reg's

rolf

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, then can you please debug a little more? It is adding X11_DIR=${x11prefix} to the

--->  Building mesa
DEBUG: Executing org.macports.build (mesa)
DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.4'
DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_rowue_macports_dports_x11_mesa/work/Mesa-7.2" && make default INSTALL_DIR=/opt/local X11_DIR=/usr/X11R6'

But the only place it does that is in a check for the existence of libX11.dylib:

~/src/macports-trunk/dports/x11/mesa $ grep -C2 X11_DIR Portfile 
	# This next hunk supports building -system_x11 mesa on a system that is otherwise +system_x11
	if {! [file exists ${prefix}/lib/libX11.dylib]} {
		build.args-append X11_DIR=${x11prefix}
		destroot.args-append X11_DIR=${x11prefix}	
	}
}

So I'm wondering if the build.args are getting set when the mesa Portfile is processed for dependencies

libX11 isn't installed, we update build.args libX11 isn't installed, we install libX11 then come back to mesa (this is jumping a few steps through libXext, but you get the idea) we come back to mesa to build it with our libX11 installed, but our build.args is already set assuming there is no libX11

...? Is that happening? That doesn't seem right to me...

[jeremyhu (Jeremy Huddleston Sequoia)]

Index: Portfile
===================================================================
--- Portfile	(revision 47330)
+++ Portfile	(working copy)
@@ -73,9 +73,11 @@
 	}
 
 	# This next hunk supports building -system_x11 mesa on a system that is otherwise +system_x11
-	if {! [file exists ${prefix}/lib/libX11.dylib]} {
-		build.args-append X11_DIR=${x11prefix}
-		destroot.args-append X11_DIR=${x11prefix}	
+	pre-build {
+		if {! [file exists ${prefix}/lib/libX11.dylib]} {
+			build.args-append X11_DIR=${x11prefix}
+			destroot.args-append X11_DIR=${x11prefix}	
+		}
 	}
 }
 

If I'm right, that above patch should fix it...

[rowue@…]

Applied your patch. otool -L after port -d configure gtkglext on clean ports now looks as expected. Went further to gwyddion.

[rowue@…]

Compiling gwyddion works - but no working openGL. OpenGL is used for 3D-Display.

Error message at startup:

bratapfel:~ rowue$ /opt/local/bin/gwyddion
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".

(gwyddion:10573): Gwydgets-WARNING **: Cannot find a double-buffered OpenGL visual, Trying single-buffered visual.

(gwyddion:10573): Gwydgets-WARNING **: No appropriate OpenGL-capable visual found.

output of glxinfo attached below

[rowue@…]

Output of glxinfo

[rowue@…]

Forget the glxinfo output it's from /usr/X11R6/bin/glxinfo

[jeremyhu (Jeremy Huddleston Sequoia)]

ok, those warlings from Xlib are just that... warnings. They're there to let you know that the server doesn't support some extensions that Xlib knows about (so some features are disabled).

The *real* reason for you not having GL support is that it can't find a visual. This is odd. Here is a patch to mesa that will build and install glxgears and glxinfo:

Index: Portfile
===================================================================
--- Portfile	(revision 47377)
+++ Portfile	(working copy)
@@ -73,9 +73,11 @@
 	}
 
 	# This next hunk supports building -system_x11 mesa on a system that is otherwise +system_x11
-	if {! [file exists ${prefix}/lib/libX11.dylib]} {
-		build.args-append X11_DIR=${x11prefix}
-		destroot.args-append X11_DIR=${x11prefix}	
+	pre-build {
+		if {! [file exists ${prefix}/lib/libX11.dylib]} {
+			build.args-append X11_DIR=${x11prefix}
+			destroot.args-append X11_DIR=${x11prefix}	
+		}
 	}
 }
 
@@ -85,11 +87,12 @@
 	#}
 
 	post-build {
-		system "cd ${worksrcpath}/../AppleSGLX-${ASGLX_version} && ${build.cmd} builds/libGL.1.2.dylib ${build.args} LDFLAGS='${configure.ldflags}' CFLAGS='${configure.cppflags} ${configure.cflags}' INSTALL_DIR='${prefix}'"
+		system "cd ${worksrcpath}/../AppleSGLX-${ASGLX_version} && ${build.cmd} programs ${build.args} LDFLAGS='${configure.ldflags}' CFLAGS='${configure.cppflags} ${configure.cflags}' INSTALL_DIR='${prefix}'"
 	}
 
 	post-destroot {
 		system "cd ${worksrcpath}/../AppleSGLX-${ASGLX_version} && ${destroot.cmd} ${destroot.target} ${destroot.destdir} ${destroot.args} INSTALL_DIR='${prefix}'"
+		system "cd ${worksrcpath}/../AppleSGLX-${ASGLX_version} && ${destroot.cmd} install_programs ${destroot.destdir} ${destroot.args} INSTALL_DIR='${prefix}'"
 		delete ${destroot}${prefix}/include/GL/glxint.h
 		delete ${destroot}${prefix}/include/GL/glxmd.h
 		delete ${destroot}${prefix}/include/GL/glxproto.h

[jeremyhu (Jeremy Huddleston Sequoia)]

Do you know what specific visual gwyddion is looking for?

[jeremyhu (Jeremy Huddleston Sequoia)]

Hmm... I wonder if it's looking for a 64bit accumbuffer... but you said this works on Leopard, right? I only see 32bit accumulation buffers in glxinfo here.

[jeremyhu (Jeremy Huddleston Sequoia)]

What is gwyddion specifying for its visual attributes with glXChooseVisual?

If you start gwyddion with: env LIBGL_DUMP__VISUALID=1 /path/to/gwyddion

When it works it should output the visual id (so run this with your "working" configuration and report that visual id as well as the corresponding glxinfo output).

[rowue@…]

Log from gwyddion on 10.5 with env LIBGL_DUMP_VISUALID=1

[rowue@…]

glxinfo from 10.5

[rowue@…]

glxinfo from 10.4

[rowue@…]

See Attachments

regs

rowue

[gstaplin@…]

rowue, what version of the X server are you using? The failure of glxinfo would seem to indicate that the X server can't get the most basic GLX visual, or GLXFBConfigs.

What does the X11 -> About X11 menu tell you the version of the X server is?

[jeremyhu (Jeremy Huddleston Sequoia)]

yeah, there should be *WAY* more visuals than that.

Your 10.5 successful setup shows you're using this visual: 0x27 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None

And on 10.4, the reason is... well like glxinfo says, you can't find any GLX visual ... so something's up with your X server...

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, there seems to be a problem when using the new libGL with the old X11 server. See the different glxinfo outputs from the two combinations.

Rowe: for now, it looks like you'll need to install xorg-server and use the new X11 server instead of the /Applications/Utilities/X11.app one.

[jeremyhu (Jeremy Huddleston Sequoia)]

new lib, new server

[jeremyhu (Jeremy Huddleston Sequoia)]

new libgl, old server

[jeremyhu (Jeremy Huddleston Sequoia)]

old libgl, new server

[jeremyhu (Jeremy Huddleston Sequoia)]

old libgl, old server

[rowue@…]

The Version of the X-Server (from about) is X11 1.1.3 - XFree86 4.4.0 last changed Feb. 2nd 2009 (from Profiler)

Can this be any kind of "communication" error between both?

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, as I showed above, there's something odd about the new libGL with the old server... just use the new server (sudo port -v install xorg-server)

[rowue@…]

Trying glxinfo with xorg-server I get:

bratapfel:~ rowue$ glxinfo 
name of display: :0.0
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  0 ()
  Serial number of failed request:  16
  Current serial number in output stream:  16
bratapfel:~ rowue$ 

gwyddion crashes when using gl

bratapfel:~ rowue$ gwyddion
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
The program 'gwyddion' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadContext'.
  (Details: serial 9490 error_code 147 request_code 0 minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
bratapfel:~ rowue$ 

X11SDK is still present - should I remove it?

reg's

rowue

[rowue@…]

The error with the combination of xorg-server and mesa still exists. Starting glxinfo from "Terminal.App" glxinfo crashes every time with the error message above. Starting glxinfo from "xterm" has a success rate of ~20%.

With this in mind I have choosen to disable OpenGL support on tiger if variant system_x11 is not set (r48111).

The crashs seems to appear during the call of glXCreateContext in function print_screen_info (just before the #ifdef GLX_VERSION_1_3)

Testsystem is an mbp (intel core duo (not core 2 duo)), XCode 2.5, OS X 10.4.11

[rowue@…]

With r48166, r48168 (xorg-server, mesa) everything works as expected - Thanks!

One issue left is a wrong error message in the Portfile of gwyddion

openGL support currently requires you to use MacPorts' X11 server (xorg-server) rather than Apple's.

even if xorg-server is installed. I would suggest pluggin in xorg-server into the Portfile of mesa rather than in the Porfile of gwyddion.

Thanks again,

rowue

[rowue@…]

PS: st like:

Index: dports/x11/mesa/Portfile
===================================================================
--- dports/x11/mesa/Portfile    (Revision 48171)
+++ dports/x11/mesa/Portfile    (Arbeitskopie)
@@ -77,6 +77,12 @@
         configure.cppflags-append -I${filespath}/include
 }
 
+platform darwin 8 {
+       if {! [variant_isset system_x11]} {
+                       depends_lib-append      port:xorg-server
+       }
+}
+
 if {! [variant_isset system_x11]} {
        default_variants +hw_render
 

[rowue@…]

Index: dports/x11/mesa/Portfile
===================================================================
--- dports/x11/mesa/Portfile    (Revision 48171)
+++ dports/x11/mesa/Portfile    (Arbeitskopie)
@@ -77,6 +77,12 @@
         configure.cppflags-append -I${filespath}/include
 }
 
+platform darwin 8 {
+       if {! [variant_isset system_x11]} {
+                       depends_lib-append      port:xorg-server
+       }
+}
+
 if {! [variant_isset system_x11]} {
        default_variants +hw_render

[(none)]

Milestone Port Bugs deleted