libcxx, libcxxabi: also install into the SDKs

[ryandesign (Ryan Carsten Schmidt)]

On Snow Leopard, the libcxx port installs libc++ into /usr/lib. But if a program uses an SDK, it can fail somewhat mysteriously. From an attempt to install cmake with libc++ on 10.6:

    /opt/local/bin/clang++-mp-3.7  -pipe -Os -stdlib=libc++ -arch x86_64  -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64  CMakeFiles/cmTC_53c5f.dir/testCXXCompiler.cxx.o  -o cmTC_53c5f 
    ld: library not found for -lc++

Because the cmake build uses -isysroot /Developer/SDKs/MacOSX10.6.sdk, it's looking for libc++ in /Developer/SDKs/MacOSX10.6.sdk/usr/lib and not finding it. Could we install it to there as well?

Xcode 3 on Snow Leopard also installs the 10.5 SDK. I'm not sure if the port should try to install to there as well if present.

Xcode 3 also optionally installs the 10.4u SDK. I assume it should not install to the 10.4u SDK since the port already does not work on Tiger.

If libcxx is modified, I assume libcxxabi should be modified too.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

Xcode 3 on Snow Leopard also installs the 10.5 SDK. I'm not sure if the port should try to install to there as well if present.

The patches I attached do this, but I guess if we do this we should really set macosx_deployment_target 10.5, huh? Would that still work ok on 10.6? I haven't tested it.

[jeremyhu (Jeremy Huddleston Sequoia)]

Thanks. Go ahead and commit them.

[jeremyhu (Jeremy Huddleston Sequoia)]

Regarding 10.4u, yes, I'd avoid adding it. I made some progress on Tiger but never got there, and things have likely only gotten worse in the past few years since I last was interested in that.

[kencu (Ken)]

I did get clang-3.8 PPC to build on Tiger, using gcc6 and libgcc to accomplish that.

[ryandesign (Ryan Carsten Schmidt)]

But what should we do for the Xcode 3.2.x user on Snow Leopard? Should we install libc++ into the 10.5 SDK also, or just into the 10.6 SDK? Will it be a problem if we install a libc++ build with MACOSX_DEPLOYMENT_TARGET=10.6 into the 10.5 SDK?

I guess the simplest would be to just say that attempting to build with libc++ on 10.6 using the 10.5 SDK is unsupported, and not install it there.

[mojca (Mojca Miklavec)]

Ticktet from long time ago: #44125

I support installing libc++ to the SDK.

Not sure about what to do for 10.5 or what to do with SDK for 10.6 on Lion where the location of that SDK is not even fixed, but depends on the Xcode version. (Maybe nothing for now?)

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca:

Ticktet from long time ago: #44125

Oh boy, yes I remember all that, thanks for the pointer. I was sure this had come up in previous tickets but couldn't find it.

I support installing libc++ to the SDK.

Not sure about what to do for 10.5

libcxx doesn't currently build on 10.5 unless you change universal_archs from ppc i386 to i386 x86_64. It doesn't build at all on 10.4 and the port prevents the build attempt. So on 10.5, if the port installs at all, it's reasonable to copy libc++ into the 10.5 SDK only and not into the 10.4u SDK.

On 10.6, which includes the 10.5 SDK if using Xcode 3 (but not if using Xcode 4), the question is whether to put it in the 10.6 SDK only or also into the 10.5 SDK.

or what to do with SDK for 10.6 on Lion where the location of that SDK is not even fixed, but depends on the Xcode version. (Maybe nothing for now?)

That's a good point. Xcode 4.1 through 4.3.x ran on Lion and included both the 10.6 and 10.7 SDK. The port currently does nothing on those systems other than install a readme. It probably makes sense to keep it that way, and therefore to match the behavior on 10.6 and not install into the 10.5 SDK there. I'll update the attachment.

It seems unlikely that someone would want to use libc++ while running on 10.6 but want to use the 10.5 SDK, or while running on 10.7 and want to use the 10.6 SDK. Apple recommends using the latest SDK, even when targeting old systems. Modern code wanting to use libc++ is more likely to accommodate that recommendation. The only time I think you might need to use an old SDK is to build really old and not-so-well-made software that was built at the time that old SDK was current, and such old software won't be using C++11.

[mojca (Mojca Miklavec)]

I'm currently using the 10.5 SDK on 10.6 in order to cross-compile TeX Live for 10.5 ppc & i386. I remember that at some point the binaries would fail to run on 10.5 otherwise (despite setting the minimum os version to 10.5), but I didn't try to check if that's still the case. And next year TL will most likely require C++11, but if MacPorts installs libc++ that won't really help me in any way since I won't be able to distribute those binaries to others without MacPorts. (I didn't yet figure out whether shipping C++11 binaries for 10.5 users and ppc users in particular is actually doable.)

Just curious: what happens if someone installs two instances of MacPorts on the same machine under a different prefix and then uninstalls libcxx on one of them?

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca:

I'm currently using the 10.5 SDK on 10.6 in order to cross-compile TeX Live for 10.5 ppc & i386. I remember that at some point the binaries would fail to run on 10.5 otherwise (despite setting the minimum os version to 10.5), but I didn't try to check if that's still the case. And next year TL will most likely require C++11, but if MacPorts installs libc++ that won't really help me in any way since I won't be able to distribute those binaries to others without MacPorts. (I didn't yet figure out whether shipping C++11 binaries for 10.5 users and ppc users in particular is actually doable.)

If you want to continue supporting 10.5 ppc, you'll have to build the package for 10.5 using FSF GCC's libstdc++ for C++11 support (i.e. the cxx11-1.1 portgroup). There's a chance such a package would still run on later OS versions. But you wouldn't be using libc++. The cxx11-1.1 portgroup is probably not currently designed to accommodate the fact that a different C++11 strategy might be needed on the deployment OS version than on the build machine OS version. The portgroup probably does not anticipate the user changing the deployment target at all, in fact. I don't know what would be involved with fixing it to do so. You could avoid the problem by building your distribution on a 10.5 machine.

Just curious: what happens if someone installs two instances of MacPorts on the same machine under a different prefix and then uninstalls libcxx on one of them?

The first time the libcxx port is installed on 10.6 or earlier, it copies libc++ into /usr/lib. The port never deletes that copy, even if the libcxx port is later deactivated or uninstalled. (#49903)

[kencu (Ken)]

nitpick. you should use ${developer_dir} instead of hardcoding it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

nitpick. you should use ${developer_dir} instead of hardcoding it.

True; done. But there's never going to be a case on 10.6 or earlier when it's not "/Developer", right? Since it is built by the buildbot, on which it is /Developer, that's what users of the binaries will get.

[ryandesign (Ryan Carsten Schmidt)]

In 25c5a3b189a85aab12185a47393c1e95aa15bfbd/macports-ports:

libcxx, libcxxabi: Use delete proc where applicable

See #55441

[ryandesign (Ryan Carsten Schmidt)]

In 9a3aaca9ea10054c6825b2b2ecf20571583c5ee1/macports-ports:

libcxx, libcxxabi: Use system's -W argument instead of cd

See #55441

[ryandesign (Ryan Carsten Schmidt)]

In 594486eb0e7b1e1f494379f8bfe83ce7e4f292ee/macports-ports:

libcxx, libcxxabi: Also install into SDK on 10.6 and earlier

Closes #55441

Fixes cmake @3.10.0 build on 10.6.