#15569: Use --x-includes and --x-libraries in certain ports to build against the 10.4u SDK X11 libraries ------------------------------------+--------------------------------------- Reporter: david@bamsoftware.com | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Resolution: | Keywords: ------------------------------------+--------------------------------------- Comment (by david@bamsoftware.com): Replying to [comment:2 ryandesign@macports.org]:
I don't think the X11 prefix should be set to /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6. Doesn't that then require that the MacOSX10.4u SDK be installed on the target system?
It doesn't seem to. I package the Nmap frontend [http://nmap.org/zenmap Zenmap] for Mac OS X using MacPorts to build its dependencies. The package runs universal on 10.4 and 10.5. I don't have a 10.4 machine to test on, so I relied on user reports to make things work on that platform. Before this change the application would crash on 10.4 with the following error: {{{ ImportError: dlopen(/Applications/Zenmap.app/Contents/Resources/lib/python2.5/gtk/_gtk.so, 2): Library not loaded: /usr/X11/lib/libXau.6.dylib Referenced from: /Applications/Zenmap.app/Contents/Resources/lib/python2.5/gtk/_gtk.so Reason: image not found }}} Linking against the 10.4u X11 headers seems to avoid this dependency on libXau, and the resultant binary runs fine on 10.5, linking against the proper libraries in /usr/X11R6: {{{ $ otool -L /Applications/Zenmap.app/Contents/Resources/lib/python2.5/gtk/_gtk.so /Applications/Zenmap.app/Contents/Resources/lib/python2.5/gtk/_gtk.so: @executable_path/../Frameworks/libgtk-x11-2.0.0.dylib (compatibility version 1201.0.0, current version 1201.9.0) ... @executable_path/../Frameworks/libpangocairo-1.0.0.dylib (compatibility version 2002.0.0, current version 2002.1.0) /usr/X11R6/lib/libSM.6.dylib (compatibility version 6.0.0, current version 6.0.0) /usr/X11R6/lib/libICE.6.dylib (compatibility version 6.3.0, current version 6.3.0) /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0, current version 6.2.0) @executable_path/../Frameworks/libcairo.2.dylib (compatibility version 20.0.0, current version 20.5.0) ... }}} (Edited for brevity.)
That's not how the SDKs should be used. I think the correct solution is to set the X11 prefix to /usr/X11R6 and set the sysroot to /Developer/SDKs/MacOSX10.4u.sdk which should take care of linking X11 things with /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6 at build time.
Forgive my ignorance. I'm new to Mac development. How should the SDKs be used? Setting the sysroot works for most packages, but a few (like these) need special treatment. I have been maintaining a patch against the ports tree that allow building a 10.4-compatible universal environment. This is one of the changes in the patch.
Have you tried setting universal_sysroot in macports.conf instead?
Yes. The MacPorts installation I use to build releases is a Subversion checkout of 1.7.0, configured as follows: {{{ export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/bin sudo mkdir /Library/Tcl/macports-universal-10.4 ./configure --prefix=/opt/local-universal-10.4 --with- tclpackage=/Library/Tcl/macports-universal-10.4 \ --with-universal-target=10.4 --with-universal- sysroot=/Developer/SDKs/MacOSX10.4u.sdk \ --with-x11-prefix=/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6 }}} Which sets universal_sysroot to {{{ universal_sysroot /Developer/SDKs/MacOSX10.4u.sdk }}} That takes care of most packages, but the ones mentioned were linking against the local 10.5 X11 libraries before this patch. -- Ticket URL: <http://trac.macports.org/ticket/15569#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS