[MacPorts] #44125: cmake needs to support building against / with a deployment target set (prevents libc++ support on Snow Leopard for cmake projects)

[MacPorts]

#44125: cmake needs to support building against / with a deployment target set
(prevents libc++ support on Snow Leopard for cmake projects)
---------------------------+--------------------------------
  Reporter:  mojca@…       |      Owner:  macports-tickets@…
      Type:  defect        |     Status:  closed
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:  fixed         |   Keywords:
      Port:  cmake libcxx  |
---------------------------+--------------------------------

Comment (by mojca@…):

 Replying to [comment:18 jeremyhu@…]:
 > Replying to [comment:17 mojca@…]:
 > > Replying to [comment:15 jeremyhu@…]:
 > > >
 > > > > On the other hand I understand that setting target to 10.6 on 10.7
 without specifying the SDK might render the resulting binary useless on
 10.6.
 > > >
 > > > Why do you say that?  The whole point of setting the deployment
 target to 10.6 means that the resulting binary will work on 10.6 unless
 there's a bug in the toolchain for some reason (which setting the sysroot
 won't solve).
 > >
 > > My personal experience is that setting just `-mmacosx-version-
 min=10.x` isn't always enough to get functional binaries.
 >
 > It is supposed to be.
 >
 > > But just `-mmacosx-version-min=10.5` certainly wasn't enough. The
 binaries kept crashing on 10.5 if I didn't set the `isysroot`. (But I no
 longer have a 10.5 machine to repeat the experiment.)
 >
 > What was the crash?  I suspect the problem was with the application
 making assumptions that were not valid and not properly checking for
 possibly-weak symbols due to functionality added by newer releases.

 I don't know and I'm unable to try without access to 10.5 or 10.4. I'm
 willing to send you the binaries though if you would like to experiment
 how exactly it fails. It took me long to figure out how to fix the build,
 but I thought that setting `-isysroot` was the suggested method to get
 reliable builds for earlier versions of Mac OS X. I thought that
 `-mmacosx-version-min=` was covering just the most trivial cases.

 > > There is also "hardcoded" SDK in
 [browser:trunk/dports/graphics/wxWidgets-2.8/Portfile wxWidgets-2.8] (see
 also the [browser:trunk/dports/_resources/port1.0/group/wxWidgets-1.0.tcl
 wxWidgets PortGroup]). From what I remember wxWidgets 2.8 doesn't compile
 on 10.7 unless the SDK for 10.6 is explicitly set.
 >
 > Why?  Is that because they hardcoded OS X versions like QT does such
 that they automatically complain or fail on new versions of the OS?

 I think that's because Carbon headers are missing. I don't think that it
 automatically fails "just because it's a new version". Or at least it
 doesn't look so.

 You can try it yourself (on 10.7 or later):
 {{{
 mkdir wxWidgets-2.8.12-build && cd wxWidgets-2.8.12-build
 $ ../wxWidgets-2.8.12/configure  --disable-shared --enable-
 macosx_arch=i386 --with-macosx-version-min=10.6
 ...
 /path/to/wxWidgets-2.8.12-build/bk-deps g++ -mmacosx-version-min=10.6 -c
 -o baselib_dynlib.o -I./.pch/wxprec_baselib -D__WXMAC__     -DWXBUILDING
 -I../wxWidgets-2.8.12/src/tiff -I../wxWidgets-2.8.12/src/jpeg
 -I../wxWidgets-2.8.12/src/png     -DwxUSE_GUI=0 -DwxUSE_BASE=1
 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
 -I/path/to/wxWidgets-2.8.12-build/lib/wx/include/mac-ansi-release-
 static-2.8 -I../wxWidgets-2.8.12/include -fpascal-strings
 -I../wxWidgets-2.8.12/src/mac/carbon/morefilex
 -I/Developer/Headers/FlatCarbon -DWX_PRECOMP -Wall -Wundef -Wno-ctor-dtor-
 privacy -O2 -fno-strict-aliasing -fno-common
 ../wxWidgets-2.8.12/src/common/dynlib.cpp
 In file included from ../wxWidgets-2.8.12/include/wx/mac/private.h:4,
                  from ../wxWidgets-2.8.12/src/common/dynlib.cpp:48:
 ../wxWidgets-2.8.12/include/wx/mac/carbon/private.h:1459: error: ‘Cursor’
 does not name a type
 ../wxWidgets-2.8.12/include/wx/mac/carbon/private.h:1488: error:
 ‘ClassicCursor’ does not name a type
 make: *** [baselib_dynlib.o] Error 1
 }}}
 While it's true that I reported results from the build with Xcode 4.6.3 (I
 don't have version 3 installed at the moment), I believe that Xcode 3.x
 should give similar results.

-- 
Ticket URL: <https://trac.macports.org/ticket/44125#comment:19>
MacPorts <http://www.macports.org/>
Ports system for OS X