Fwd: Apple notarisation process - LC_VERSION_MIN_MACOSX
sent this to the dev list due to finger slip on ipad buttons... -- Forwarded message -- From: *Ken Cunningham* Date: Wednesday, March 3, 2021 Subject: Apple notarisation process - LC_VERSION_MIN_MACOSX To: macports-dev We really should have MacPorts libs be utilizable by projects that want to put them on the App Store or use them any way they want to use them, if at all possible. The LC_VERSION_MIN_MACOSX issue is interesting. There is lots of code in ld64 that appears designed to add this, and to fall back on the DEPLOYMENT_TARGET to set it if it's not on the command line, and to handle mismatches between the DEP target and the command line. And yet I too can't see that chunk being added to dylibs either using xcode ld64 or ld64-latest, whether building from source or downloaded from the buildbot. Something is amiss -- not sure it is a MacPorts issue, exactly, at this moment. I await inspiration or insight... K
re: clang++ and libc++
As of clang-11, the most current libc++ is installed tucked away in the llvm-11 libs dir. There is both a dylib (rpathed) and a static libc++ there. I set this up for now for people like you to use for exactly this. You will have to force it (DYLD_LIBRARY_PATH, possibly static link it, or some other way). It's new. Please feel free to let me know how it works for you. Ken (maintainer of toolchains - clang and libc++, cctools, ld64, tapi - on MacPorts)
Re: clang++ and libc++
On Mar 3, 2021, at 03:59, Paul Floyd wrote: > Hi > > A slightly off topic question. I have two macbooks, and the old one I use for > testing the build of Valgrind when I'm wearing my opensource hat. > > The Mac is running 10.7.5. XCode for this platform is too old to build the > current Valgrind source, so I'm using clang 9.0.1 from macports. > > This mostly works, at least for building the code, but there is an issue with > C++ code. There are some regression tests that use 'modern C++' (my fault!). > These use automake configure tests to check that the compiler supports these > features. This works OK, but when it comes to linking there is a failure. > > For instance, one test covers C++14 sized deallocation. > > > The configure test is > > AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[ > return 0; > ]])], [ > FLAG_FSIZED_DEALLOCATION="-fsized-deallocation" > ac_have_sized_deallocation=yes > AC_MSG_RESULT([yes]) > ], [ > FLAG_FSIZED_DEALLOCATION="" > ac_have_sized_deallocation=no > AC_MSG_RESULT([no]) > ]) > > and the link error is > > /opt/local/bin/clang++-mp-9.0 -Winline -Wall -Wshadow -Wno-long-long -g > -fno-stack-protector -Wno-unused-private-field -arch x86_64 > -fsized-deallocation -o sized_delete sized_delete-sized_delete.o > Undefined symbols for architecture x86_64: > "operator delete[](void*, unsigned long)", referenced from: > _main in sized_delete-sized_delete.o > "operator delete(void*, unsigned long)", referenced from: > _main in sized_delete-sized_delete.o > ld: symbol(s) not found for architecture x86_64 > > > So my question, is there a way to get such code to link with clang++ on such > an old platform? Or does in only use /usr/lib/libc++.1.dylib and so is > limited to the C++ library features present in that library? If you're trying to create software that will work on other people's Mac OS X 10.7 systems too, then you're limited to the C++ features present in /usr/lib/libc++.1.dylib. If you don't care about compatibility with other people's systems and only need it to work on your system, you can install the libcxx port with the +replacemnt_libcxx variant. (See "port variants libcxx".) This will replace /usr/lib/libc++.1.dylib with a newer version from MacPorts. MacPorts will not preserve a backup copy of your old /usr/lib/libc++.1.dylib so you should make a copy in a safe place in case you want to revert to it later.
clang++ and libc++
Hi A slightly off topic question. I have two macbooks, and the old one I use for testing the build of Valgrind when I'm wearing my opensource hat. The Mac is running 10.7.5. XCode for this platform is too old to build the current Valgrind source, so I'm using clang 9.0.1 from macports. This mostly works, at least for building the code, but there is an issue with C++ code. There are some regression tests that use 'modern C++' (my fault!). These use automake configure tests to check that the compiler supports these features. This works OK, but when it comes to linking there is a failure. For instance, one test covers C++14 sized deallocation. The configure test is AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[ return 0; ]])], [ FLAG_FSIZED_DEALLOCATION="-fsized-deallocation" ac_have_sized_deallocation=yes AC_MSG_RESULT([yes]) ], [ FLAG_FSIZED_DEALLOCATION="" ac_have_sized_deallocation=no AC_MSG_RESULT([no]) ]) and the link error is /opt/local/bin/clang++-mp-9.0 -Winline -Wall -Wshadow -Wno-long-long -g -fno-stack-protector -Wno-unused-private-field -arch x86_64 -fsized-deallocation -o sized_delete sized_delete-sized_delete.o Undefined symbols for architecture x86_64: "operator delete[](void*, unsigned long)", referenced from: _main in sized_delete-sized_delete.o "operator delete(void*, unsigned long)", referenced from: _main in sized_delete-sized_delete.o ld: symbol(s) not found for architecture x86_64 So my question, is there a way to get such code to link with clang++ on such an old platform? Or does in only use /usr/lib/libc++.1.dylib and so is limited to the C++ library features present in that library? A+ Paul
