I compiled my App using Qt 5.3.2 on my Mac OS X 10.9 and it runs on Mac OS X 10.6 without any issue. But due to a bug in Qt 5.3.2 (unfixed) which causes the apps to crash on maximizing, if focus is on tree view, I had to switch to Qt 5.4.
After compiling my app using Qt 5.4 on Mac OS X 10.9, it no more runs on Mac OS X 10.6. It crashes with the error:
dyld: library not loaded: /usr/lib/libc++.1.dylib Qt
After some searching I figured out that
Running Qt apps on Mac OS X 10.6 is not supported by Qt 5.4 binaries available on Qt Website. A custom build is required for the same.
As per one source:
To make clang++ produce binaries compatible with g++ from llvm-gcc-4.2.1, use these compiler and linker flags: -stdlib=libstdc++ -mmacosx-version-min=10.6
These will make sure we link with the 10.6 CRT and that we do not link with libc++ (the default C++ library for clang++).
For custom build:
./configure -prefix $PWD/qtbase -opensource -no-c++11 -debug-and-release -nomake examples -nomake demos
10.6 is no longer supported in Qt 5.4
If you even compile it manually using -no-c++11, your app resulting executable will crash on 10.6
5.3.2 is the last to support 10.6 with -no-c++11
Related
The official way to compile universal binaries that target Apple's new M1 processor is to use Xcode 12, which requires at minimum macOS 10.15.4. I'm currently running macOS 10.14.6 though and do not want to upgrade if I can avoid it. Is there an unofficial way to compile such a universal binary when running macOS 10.14?
This is possible to do. Of course it can't be done with Xcode on its own since Apple has long since dropped support for macOS 10.14 in its developer tools, but can be down either by compiling from the command line or using another build system like cmake or qmake.
It at minimum requires two things:
A newer macOS SDK than is officially supported in macOS 10.14, obtained from Xcode 12.2 or later
A newer version of LLVM / clang that is compatible the macOS SDK from the version of Xcode you obtained
You can actually get both things by downloading the latest release of Xcode, since as of the time of this writing (December 2022) the release of LLVM included in the latest release of Xcode (14.2) will still run in macOS 10.14.
Should that ever stop working, though, or if you would prefer not to use Xcode's release of LLVM, you can also install a newer version of LLVM and clang using MacPorts, as MacPorts continues to support older macOS releases (unlike Homebrew). The command would be sudo port install clang-15, or whatever the latest available major release of clang is.
Another option is to built and install your own copy of LLVM and clang, and the steps to do so are laid out in LLVM's documentation.
For best results, the version of LLVM should be the same major version or newer than the version of LLVM / clang included in the release of Xcode you obtained.
Once you have both of those, you can compile C, C++, or Objective-C and probably Swift with a command like:
/path/to/newer/clang \
-arch x86_64 -arch arm64 \
-isysroot /path/to/Xcode14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk \
source.m source2.cpp source3.c ...
If you installed clang using MacPorts, then its path would be something like /opt/local/bin/clang-mp-15.
In the case of only using a newer release of Xcode, you can do it like this:
/path/to/Xcode14.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang \
-arch x86_64 -arch arm64 \
-isysroot /path/to/Xcode14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk \
source.m source2.cpp source3.c ...
I've only tested this with C, C++ and Objective-C so far, and not Swift, but presumably it will work for Swift as well.
Note that if you want to target macOS 10.14, it's still necessary to avoid using parts of the macOS SDK as well as C++ and Swift features that require macOS 10.15 or later.
(It may be possible to at least make use of newer C++ features in macOS 10.14 and earlier if you build your own universal binaries of LLVM's runtimes (namely libc++ and libc++abi) from the later release of LLVM, and then compile your code with the arguments -nostdlib, statically link to libc++ and libc++abi, and then explicitly link to /usr/lib/libSystem.B.dylib. But so far I haven't managed to get an arm64 copy of LLVM's runtimes to compile in macOS 10.14.)
Short answer: No
Why?
Apple did it. There's a doc from apple here
You will have to use Xcode 12.2 and above. You must upgrade to MacOS 10.15.4+ or 11 to benifit the latest feature.
Apple brings the tool lipo to convert binaires for ARM64 and AMD64 architectures.
With Apple silicon, you can compile binaries for ARM64 and AMD64. You can debug ARM64 binaries naturally. You can debug AMD64 binaries under Rosetta translation.
With Intel x86 chips, you can compile binaries for ARM64 and AMD64. You can debug AMD64 binaries naturally. But you cannot debug ARM64 binaries under Rosetta translation.
This means Apple Silicon's ARM64 architecture can do more on MacOS. It's unfair for AMD64 chips. Tipical Apple. Hopefully someone can come out and unseals the secret Apple silicon. But I don't think apple would like to share. If Intel/AMD wake up and bring us more powerful chips which can compile/debug ARM64 binaries for MacOS, apple wouldn't be happy with their sales. For the longterm, we won't be able to do it (seemingly). Apple kicked Nvidia away years ago, now Intel, soon AMD. Mark it here. 10 years later, let's see.
I'm running Mac OS X 10.6 and want to install TextMate 2, which is for Mac OS X 10.7+.
But all what it needs is a newer version of clang (LLVM), which is included in Lion and Mountain Lion. I read before here I can do that with MacPorts. So I used port install clang and MacPorts updated to clang-2.9, then clang-3.2 and finally clang-3.3. I thought, its updated now and I checked the version: clang --version. And it's not updated:
Apple clang version 2.0 (tags/Apple/clang-139) (based on LLVM 2.9svn)
Target: x86_64-apple-darwin10
Thread model: posix
So I copied the new clang file in this path (/opt/local/libexec/llvm-3.3/bin) to/usr/bin`. But now there's a fail :( :
dyld: Library not loaded: #executable_path/../lib/libLLVM-3.3svn.dylib
Referenced from: /usr/bin/clang
Reason: image not found Trace/BPT trap
The libLLVM-3.3svn.dylib is at /opt/local/libexec/llvm-3.3/lib. What can I do now, that
it runs clang-3.3? Sorry for my not perfect english ;) Thank you!
If you run clang from /usr/bin, it will be looking for the LLVM library in /usr/bin/../lib/libLLVM-3.3svn.dylib, i.e., /usr/lib/libLLVM-3.3svn.dylib (at least that's what the dynamic loader is telling you). You could try to copy the lib file into /usr/lib.
Alternatively, you can just download a more recent official build of Clang here:
http://llvm.org/releases/download.html
As far as I know, these builds are self-contained and do not need any dynamic libraries. However, it could be necessary to copy Apple's ARC libraries into a certain directory. If you run into trouble, please ask again.
Another approach is to build Clang and LLVM from source. You can find the repository URLs and instructions here:
http://clang.llvm.org/get_started.html
This should also build Clang with the LLVM libraries statically linked.
3.3, by the way, has not been officially released, so I would recommend using 3.2 unless you need any specific new features.
I'm trying to build a static, universal Qt from source on Mac OS X 10.6 using the following command:
sh configure -static -opensource -universal
The problem, I have been told, is that PPC is not supported on 10.6 so I am getting many errors and the build eventually fails.
So I need to build for a different target version of OS X - 10.4 or 10.5. How can I do that? Do I need to add some parameters to my configure line and, if so, which ones?
Try using the -sdk option to configure. e.g.
./configure -sdk /Developer/SDKs/MacOSX10.5.sdk -opensource -universal
...if you want to make binaries targeting OSX 10.5 and later.
Statically linking is a separate issue again. I would not recommend it, especially since OSX already supports app bundles anyway, which I believe gives most of the same benefits to the end-user as static linking.
I'd like to compile my application for version 10.5 and forward. Ever since I upgraded to Snow Leopard and installed the latest XCode, gcc defaults to 10.6. I've tried -isysroot /Developer/SDKs/MacOSX10.5.sdk but that doesn't seem to work. Is there a GCC flag that allows me to set the SDK?
(Incidentally, I changed the gcc symbolic link to point to gcc-4.0 instead of gcc-4.2 and it worked but I thought I could tell the latest GCC to compile for an older SDK).
Thanks,
Rui
In XCode you only need to set the deployment target to OSX 10.5.
For gcc you need to set -mmacosx-version-min=10.5.
I'd like to compile a fortran code with gfortran so that it will work on both Mac OS X 10.5 and 10.6. Is there a way to do this? I tried compiling on 10.6 and get this message when I run the executable on 10.5:
dyld: unknown required load command 0x80000022
Trace/BPT trap
What version of 10.5 are you on? According to this (0x22) is a dynamic load function that got added at 10.5.6. You could try upgrading to >10.5.6 and see if the problem persists.
Also where did you get your gfortran from? In the numpy community the ones from att.com are highly recommended and the builds from hpc are generally to be avoided.
The application was incorrectly built on OS X 10.6 machine for a 10.5 machine. The developer can fix this by considering three things:
Using the correct compiler parameters:
gcc-4.2 -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk ...
Using the correct linker settings (setting environment variable before link command). This is required, so that the OS X 10.6 linker will not use the loader command 'LC_DYLD_INFO_ONLY' (=0x80000022), because OS X 10.5 does not understand this command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
After this is fixed, one can check if the application was correctly built for OS X 10.5 by running 'otool':
otool -l binary
The correct binary should not contain any 'LC_DYLD_INFO_ONLY' load commands (only 'LC_DYLD_INFO' commands).
(also see my blog article http://grauonline.de/wordpress/?p=71 )