Opened 7 years ago
Closed 7 years ago
#55441 closed enhancement (fixed)
libcxx, libcxxabi: also install into the SDKs
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | snowleopard haspatch | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), mojca (Mojca Miklavec), kencu (Ken) |
Port: | libcxx, libcxxabi |
Description
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.
Attachments (2)
Change History (18)
comment:1 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
comment:2 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Thanks. Go ahead and commit them.
comment:3 Changed 7 years ago by 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.
comment:4 Changed 7 years ago by kencu (Ken)
I did get clang-3.8 PPC to build on Tiger, using gcc6 and libgcc to accomplish that.
comment:5 Changed 7 years ago by 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.
comment:6 Changed 7 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Cc: | MarcusCalhoun-Lopez added |
---|
comment:7 Changed 7 years ago by mojca (Mojca Miklavec)
Cc: | mojca added |
---|
comment:8 follow-up: 9 Changed 7 years ago by 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?)
comment:9 Changed 7 years ago by 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.
comment:10 follow-up: 11 Changed 7 years ago by 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?
comment:11 Changed 7 years ago by 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)
comment:12 follow-up: 13 Changed 7 years ago by kencu (Ken)
nitpick. you should use ${developer_dir} instead of hardcoding it.
Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Attachment: | libcxx.diff added |
---|
Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Attachment: | libcxxabi.diff added |
---|
comment:13 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | kencu added |
---|
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.
comment:14 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
comment:15 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
comment:16 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Replying to ryandesign:
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.