cmake needs to support building against / with a deployment target set (prevents libc++ support on Snow Leopard for cmake projects)

[mojca (Mojca Miklavec)]

When compiling against libc++ on 10.6 CMake fails to work because:

• the cmake PortGroup adds

  -DCMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.6.sdk" \
  -DCMAKE_OSX_DEPLOYMENT_TARGET="10.6"
  

• even if CMake PortGroup wouldn't add those variables, CMake seems to add -isysroot automatically unless the above variables are set to blank:

  -DCMAKE_OSX_SYSROOT="/" \
  -DCMAKE_OSX_DEPLOYMENT_TARGET=""
  

This looks partially as an upstream "bug", partially as a bug in the portgroup, see comment:7:ticket:44062. But maybe it's considered a feature to help developers link against an earlier framework?

The main question is: should this be fixed? Upstream? In MacPorts? Or not at all? Should we set the flags to empty perhaps (unless a different SDK is required)? Or maybe libc++ should also be installed inside the SDK?

This is likely not only an issue with libc++. libc++ is just an example that was affected.

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca@…:

When compiling against libc++ on 10.6 CMake fails to work

In what way? Can you attach a main.log?

[mojca (Mojca Miklavec)]

See #44062.

The compilation fails with:

ld: library not found for -lc++

because there is no libc++.dyldb inside /Developer/SDKs/MacOSX10.6.sdk. One possible solution would be to symlink/copy libc++ also to the SDK (which might include doing the same on Lion in case that the 10.6 SDK is present; the SDK for 10.6 could be used for wxWidgets for example, but then again wxWidgets doesn't use CMake, so it's not an issue).

The other solution would be to set

-DCMAKE_OSX_SYSROOT="/" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=""

by the CMake PortGroup unless explicitly requested otherwise.

[Ionic (Mihai Moldovan)]

libc++ should be pretty much the only software affected, for one reason: it's not shipped or supported by Apple, but has to be prominently installed into /usr/lib. It's a really rare occasion, as most software is bundled within ${prefix} by MacPorts. {prefix}/lib and ${prefix}/include are automatically added by MacPorts and -isysroot can't shadow them (although this statement might be inaccurate depending on the position of the additional -I/-isystem/-L flags compared to -isysroot) so problems like that can't occur.

The other thing is that /Developer/SDKs/... is and should remain Apple-land only. Installing libc++ to that place is "dirtying" the SDKs, which sounds like a bad idea to me.

I'd even let the cmake PortGroup as-is, with one little change: on 10.6 (and maybe 10.7? I have never used 10.7, so no idea whether MacPorts installed libc++ into /usr/lib on 10.7 as well or Apple ships it themselves, which would alleviate the problem altogether), and if libc++ is explicitly requested/set (the default is libstdc++ anyway), set

-DCMAKE_OSX_SYSROOT="/" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=""

else keep the current behavior.

[jeremyhu (Jeremy Huddleston Sequoia)]

by the CMake PortGroup unless explicitly requested otherwise.

Yeah, the CMake PortGroup should honor configure.sdk_version and configure.sdkroot ... is that not the case right now?

base does:

        # add SDK flags if cross-compiling (or universal on ppc tiger)
        if {${configure.sdkroot} ne ""} {
            foreach env_var {CPPFLAGS CFLAGS CXXFLAGS OBJCFLAGS OBJCXXFLAGS} {
                append_to_environment_value configure $env_var -isysroot ${configure.sdkroot}
            }
            append_to_environment_value configure "LDFLAGS" -Wl,-syslibroot,${configure.sdkroot}
        }

[jeremyhu (Jeremy Huddleston Sequoia)]

cmake-44125.patch

[jeremyhu (Jeremy Huddleston Sequoia)]

How about something like this?

[mojca (Mojca Miklavec)]

I remember that I also had to set -DCMAKE_OSX_DEPLOYMENT_TARGET="", but I'm not sure why exactly and I might be wrong. I can check.

But see also Ryan's comment:

This should no longer be an issue since the cmake portgroup now always sets the SDK.

[jeremyhu (Jeremy Huddleston Sequoia)]

r122298

[jeremyhu (Jeremy Huddleston Sequoia)]

Reopening as that caused regressions.

[NicosPavlov]

Cc Me!

[jmroot (Joshua Root)]

To give some background and history on this issue:

#29008, #37527, #41321

r60805, r66929, r73038, r78651, r101141, r101169, r101420, r119436

[jeremyhu (Jeremy Huddleston Sequoia)]

cmake.patch

[jeremyhu (Jeremy Huddleston Sequoia)]

Attached proposed change to cmake (in addition to reverting r122300).

[mojca (Mojca Miklavec)]

Seeing how many times things have changed and given that every change affects a different scenario, I think these issues with CMake deserve a "serious" test suite to avoid constant problems when introducing further changes.

See also #41783 which is related to this change. If that ticket gets implemented, we would really need to install libc++ to a different place.

I cannot comment on the patch because I don't fully understand it, but I would prefer to see some discussion with the upstream CMake developers if possible, so that we don't start diverging from their code too much.

CMake serves both for installing ports for MacPorts as well as a standalone utility that users can use for external projects. If we diverge from the original too much just for the sake of smoother installation of other MacPorts software, that might influence regular CMake users. So we should fix this with coordination with upstream.

I agree that it's totally weird that CMake requires setting both SDK and target version at the same time. (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. So CMake tries to be over-protective to its users. But it's pointless to require setting the SDK when building for the same/default target. But then again CMake's search algorithm for libraries and headers in FindFoo.cmake is totally weird, non-configurable etc. And setting the SDK explicitly probably avoids a couple of problems related to CMake's bad design decisions.)

[jeremyhu (Jeremy Huddleston Sequoia)]

The patch just makes it such that / can be chosen as a syslibroot when setting a deployment target... the exact thing we're trying to do in the PortGroup

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

[jeremyhu (Jeremy Huddleston Sequoia)]

r122338 r122339. We should send this patch (and the others in our repo) upstream as well, so we're not carrying along a bunch of patches to workaround upstream bugs.

[mojca (Mojca Miklavec)]

Replying to 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. Sometimes it works, but often one also needs to set other variables. For compiling TeX binaries I'm currently using the following variables for example:

export arch=i386
export MYLDFLAGS="-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib"
export MYSYSROOT="-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5"
export CFLAGS="-arch $arch $MYSYSROOT"
export CXXFLAGS="-arch $arch $MYSYSROOT"
export OBJCFLAGS="-arch $arch $MYSYSROOT"
export OBJCXXFLAGS="-arch $arch $MYSYSROOT"
export LDFLAGS="-arch $arch $MYLDFLAGS $MYSYSROOT"

Maybe having both -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib and -isysroot /Developer/SDKs/MacOSX10.5.sdk is too much. 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.)

There is also "hardcoded" SDK in wxWidgets-2.8​ (see also the wxWidgets PortGroup​). From what I remember wxWidgets 2.8 doesn't compile on 10.7 unless the SDK for 10.6 is explicitly set.

Please also leave some feedback on #41783.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to mojca@…:

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

There is also "hardcoded" SDK in wxWidgets-2.8​ (see also the 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?

[mojca (Mojca Miklavec)]

Replying to jeremyhu@…:

Replying to mojca@…:

Replying to 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 wxWidgets-2.8​ (see also the 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.

[mojca (Mojca Miklavec)]

See also

• ​https://github.com/Homebrew/homebrew/issues/6672 (and #30272)

[jeremyhu (Jeremy Huddleston Sequoia)]

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

[mojca (Mojca Miklavec)]

I have found the old emails about why the extra SDK flags were needed for tex binaries. The software was using autotools to determine the properties.

I first used just

export MACOSX_DEPLOYMENT_TARGET=10.4

on 64-bit 10.6, cross-compiling for PPC and i386 Tiger. But at some point (when updating to a newer version) this stopped working.

The configure tests ended up with:

/* Define to 1 if you have the `stat64' function. */
#define HAVE_STAT64 1

when they should have failed when compiling for Tiger.

The test was trying to figure out if start64() worked. These were my own results:

> cat abc.c
int main()
{
        return stat64();
        return 0;
}

> gcc -arch i386 -mmacosx-version-min=10.4 abc.c
[all goes fine]

> gcc -arch i386 -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk abc.c
Undefined symbols:
  "_stat64", referenced from:
      _main in ccl8dKsi.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

> gcc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk abc.c
ld: library not found for -lcrt1.10.6.o
collect2: ld returned 1 exit status

The configure somehow concluded that stat64 was supposed to work.

At the end only LDFLAGS="-arch $ARCH -L/Developer/SDKs/MacOSX10.4u.sdk/usr/lib $LDFLAGS" solved the problem for me (to compile that particular software).

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, that's the problem with autoconf based approaches. A better approach might be to check if stat64 is a weak symbol. If it is weak, then perhaps HAVE_STAT64 could be 0 and we could have a new macro (HAVE_WEAK_STAT64) defined to 1. Code which builds based on the HAVE_STAT64 macro (and just calls it unconditionally) will work by falling back to the old codepath even though stat64 is conditionally available. Similarly, it allows developers to conditionally use stat64 with runtime checks if they know what they're doing with HAVE_WEAK_STAT64.

But that's an autoconf bug, and autoconf is GPLv3, so I'm not going to touch it ;)

[mojca (Mojca Miklavec)]

I don't think it's an autoconf problem only. (The code for HAVE_STAT64 is gone from our sources already, but nonetheless.)

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

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

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? But that includes changes in C/C++ sources as well, right? 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.)

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.

(Weak linking would be better of course, but the basic problem/bug that caused Bus error was elsewhere. Is any configuration check needed at all when weak linking is used? I would think that configuration is then only needed on other platforms.)

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to 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?

[mojca (Mojca Miklavec)]

I have submitted a bug report to ​http://www.cmake.org/Bug/view.php?id=15040

I'll get to the other issues later. (It's a lot to process. :)

[mojca (Mojca Miklavec)]

This has been fixed upstream. See ​http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5b4faeef