[MacPorts] #15569: Use --x-includes and --x-libraries in certain ports to build against the 10.4u SDK X11 libraries

[MacPorts]

#15569: Use --x-includes and --x-libraries in certain ports to build against the
10.4u SDK X11 libraries
------------------------------------+---------------------------------------
  Reporter:  david at bamsoftware.com  |       Owner:  macports-tickets at lists.macosforge.org
      Type:  defect                 |      Status:  new                                  
  Priority:  Normal                 |   Milestone:  Port Enhancements                    
 Component:  ports                  |     Version:  1.7.0                                
Resolution:                         |    Keywords:                                       
------------------------------------+---------------------------------------
Comment (by david at bamsoftware.com):

 Replying to [comment:2 ryandesign at 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