[MacPorts] #17558: connection errors when macports libs are used with Tiger X11 headers

[MacPorts]

#17558: connection errors when macports libs are used with Tiger X11 headers
----------------------------------+-----------------------------------------
  Reporter:  vinc17@…             |       Owner:  jeremyhu@…           
      Type:  defect               |      Status:  reopened             
  Priority:  High                 |   Milestone:  Port Bugs            
 Component:  ports                |     Version:  1.6.0                
Resolution:                       |    Keywords:  crash                
      Port:  xorg                 |  
----------------------------------+-----------------------------------------

Comment(by david@…):

 Replying to [comment:24 ryandesign@…]:
 > Replying to [comment:22 jmr@…]:
 > > The problem may be that gtk2 (and others) has:
 > > configure.args-append       --x-includes=${x11prefix}/include
 > >                                 --x-libraries=${x11prefix}/lib
 > > So it's going to be preferring the /usr/X11R6 bits on Tiger. I think
 those configure args are safe to remove now that (a) pkgconfig looks in
 x11prefix, and (b) we have working xorg ports for Tiger.
 > But there were tickets that specifically requested --x-includes and
 --x-libraries be added to several ports, e.g. #15569.

 I'm the one who requested --x-includes and --x-libraries in #15569. For
 what it's worth, removing them breaks cairo, pango, and gtk2 for my
 purposes. I have to build universal libraries that are compatible with
 10.4 and 10.5. That means that they must not be linked against the 10.5
 X11 libraries in /usr/X11, because some of them like libXau are not in
 10.4. (I'm running 10.5.)

 From a checkout of r44619 I rebuilt a new environment from scratch. I
 installed py25-gtk, py25-py2app-devel, py25-sqlite, and py25-zlib and all
 their dependencies. The packages are linking against the libraries in
 /usr/X11. Here are excerpts from building gtk2:

 {{{
 checking for X... libraries /usr/X11/lib, headers
 checking Pango flags... -I/opt/local-universal-10.4/include/pango-1.0 ...
 -L/usr/X11/lib -lpangocairo-1.0 -lcairo -lXrender -lSM -lICE -lX11 ...
 }}}

 The resulting libraries are linked against libXau:

 {{{
 /opt/local-universal-10.4/lib/libgtk-x11-2.0.dylib:
         /opt/local-universal-10.4/lib/libgtk-x11-2.0.0.dylib
 (compatibility version 1401.0.0, current version 1401.5.0)
         /opt/local-universal-10.4/lib/libgdk_pixbuf-2.0.0.dylib
 (compatibility version 1401.0.0, current version 1401.5.0)
         /opt/local-universal-10.4/lib/libgdk-x11-2.0.0.dylib
 (compatibility version 1401.0.0, current version 1401.5.0)
         /usr/X11/lib/libXi.6.dylib (compatibility version 7.0.0, current
 version 7.0.0)
         /usr/X11/lib/libXinerama.1.dylib (compatibility version 2.0.0,
 current version 2.0.0)
         /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0,
 current version 11.0.0)
         ...
         /usr/X11/lib/libXrender.1.dylib (compatibility version 5.0.0,
 current version 5.0.0)
         /usr/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current
 version 7.0.0)
         /usr/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current
 version 10.0.0)
         /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current
 version 9.0.0)
         /usr/X11/lib/libXau.6.dylib (compatibility version 7.0.0, current
 version 7.0.0)
         /usr/X11/lib/libXdmcp.6.dylib (compatibility version 7.0.0,
 current version 7.0.0)
         ...
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 111.0.0)
         ...
         /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
 (compatibility version 2.0.0, current version 136.0.0)
         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
 version 1.0.0)
 }}}

 If I restore the --x-includes and --x-libraries then the dependency on
 libXau goes away. (My MacPorts is configured with
 x11prefix=/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6 so only
 10.4-compatible libraries are used.)

 I agree that this would be better solved by having packages detect the
 correct location of X11 through Autoconf or whatever. This change is no
 big deal for me; until the packages are fixed I can just add --x-includes
 and --x-libraries back to my private patch.

-- 
Ticket URL: <http://trac.macports.org/ticket/17558#comment:43>
MacPorts <http://www.macports.org/>
Ports system for Mac OS