[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:24 mojca@…]:
 > I don't think it's an autoconf problem only. (The code for `HAVE_STAT64`
 is gone from our sources already, but nonetheless.)

 No, it's not *just* an autoconf problem, but autoconf does not actually
 provide the useful information for developers to make intelligent
 decisions with.

 > I was aware of the function `respondsToSelector` in Cocoa. I wasn't
 aware of existence of "weak linking" for "regular code".

 if (&someSymbol) {
   someSymbol(...);
 } else {
   someOtherSymbol(...);
 }

 > So the following tutorial is semi-wrong about the need for using
 `-isysroot`?
 >   * http://www.cocoawithlove.com/2009/09/building-for-earlier-os-
 versions-in.html

 Yes.

 > From what I understand every developer should be aware of Mac-specifics
 then and try to write the code in such a way that weak linking would work
 properly?

 This isn't a Mac-specific problem.  The same is true on every other OS,
 but most other OS's do not support letting you set a deployment target to
 older releases.  For example, if you have a libc variant that contains
 strlcat() on Linux and you configure and build something that uses strlcat
 on that system, it won't run on a flavor of linux with glibc which doens't
 have strlcat.  To combat this, Linux build systems are set to the MINIMUM
 supported version for the product that is being built.  This means that
 the resulting product won't have access to strlcat in my example because
 it simply won't be on the *build* system even though it *might* be
 available at runtime.  If you really want to live in the same world as
 that, you can do so (by using an older SDK or building on an older OS
 version), but that is extremely limiting and prevents adoption of
 technologies simply because your minimum-supported OS doesn't have them.

 Instead, Apple encourages developers to build against the newest SDK,
 which includes annotation of when symbols became available.  It is up to
 the developer to know if these technologies are conditionally available
 based on their chosen deployment target and adjust their code accordingly.

 autoconf can help "bridge the gap" here using the approach I outlined
 above, by setting HAVE_STRLCAT (and similar) macros only when the method
 is guaranteed to be present, it will allow us to use existing projects
 with the current SDK and an older deployment target without changes.  If
 we want to conditionally adopt functionality that might be present in
 versions newer than the deployment target, then we can start checking the
 HAVE_WEAK_STRLCAT (and similar) symbols.

 > But that includes changes in `C/C++` sources as well, right?

 Yeah.

 > Does CMake make it any easier to support weak linking? (It's difficult
 enough to find resources online. I found some, but they contain some
 relatively ugly mac-specific code to support weak linking.)

 I have no idea.  I don't mess with cmake projects much.  They may have the
 same problem as autoconf, or they may have solved it like I suggested, or
 they may have solved it another way.

 > But unless I'm mistaken you are describing/solving a '''slightly'''
 different problem with weak linking. In that particular case I would be
 perfectly happy if `stat64` wouldn't be called on a system that supports
 it. As long as the binaries work, I'm happy, I don't need heavily
 optimized code. The problem is that the check for `stat64` was successful
 when it shouldn't have been.

 It was successful because it was present in the linktime libraries, and
 autoconf assumes that the runtime will be a superset of the linktime.  The
 OS X toolchain supports runtime being a subset of the linktime
 environment.

 > (Weak linking would be better of course

 What do you mean by that?  The issue you were seeing involved weak
 linking.  stat64 was a weak symbol, and it wasn't in the older OS version,
 so the symbol was NULL at runtime, so when it was called, you crashed.
 That is weak linking.

 > , but the basic problem/bug that caused `Bus error` was elsewhere.

 No.  It was caused because stat64 was a weak symbol that was not checked
 before being dereferenced.

 > Is any configuration check needed at all when weak linking is used?

 Whenever you link against a symbol weakly, you need to check for its
 existence at runtime.

 > I would think that configuration is then only needed on other
 platforms.)

 I'm not sure what you mean by this last point, sorry.  Can you elaborate?

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