[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 jeremyhu@…):

 Replying to [comment:19 mojca@…]:
 > > > 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.

 Sure.  I have a 10.5 VM that I can boot up to test them.

 > 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.

 The main issue is that much OSS software assumes that what is discovered
 at configure time will be available at runtime, but that might not be
 true.  For instance, I added some POSIX08 and C11 functions to Lion's Libc
 (eg: memmem, strndup, strnlen, stpncpy, getline, getdelim, dprintf, and
 others).  The code may assume that if it sees one of these functions at
 build time that it will be available at runtime, but that is not
 necessarily the case.  If the deployment target is lower than when these
 symbols were added, they will be weak, and the code should check for their
 existence before usage.

 > > 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
 > }}}

 There are no missing headers reported.  The issue is that the code was
 using QuickDraw.  QuickDraw was deprecated in OS X 10.5 and was finally
 removed in OS X 10.7.

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