> and the command I used is: > *% sudo port install llvm-10 +universal* > > But, what I see is: > *% otool -l /opt/local/libexec/llvm-10/lib/libLLVM.dylib| grep "minos\|sdk"* > minos 11.0 > sdk 11.1 > > The sdk version looks fine, but why the minos is 11.0? shouldn't it be > 10.14 as expected? What am I missing?
Well, you’re the first person I know of who has tried this, but I get what you’re up to — here are my thoughts: When you try to build things universal, it happens in one of two ways. Either MacOS can build it as universal “in one go” with multiple arch flags, or MacOS cannot build it like that and you need to build it twice, once with each arch, and lipo them together. MacPorts does the automatic lipoing together using a mechanism set up in the “muniversal” PortGroup. When you build llvm-10, it’s a “one go” multiarch build. I don’t think that the compiler would know exactly what to do with a build line like this: clang++ -arch arm64 -arch x86_64 -macosx-version-min=10.14 … There is no way you can hope to build arm64 for a macosx-version-min of 10.14 (arm64 requires a version min of 11.0 I imagine). So, it is quite possible that to be helpful, it ignores your macosx-version-min=10.14 as being a likely “mistake” and bumps your macosx-version-min to something reasonable, like minos 11.0. If, however, you built it separately and lipo’d them together yourself (or using the muniversal PG) something might be built that has one macosx-version-min for arm64 and a different macosx-version-min for x86_64. I would say — Yuk. Are you sure you want to build this exactly? If you did want to build a univeral binary that runs on x86_64 from 10.14 up, and on arm64, you might well have to build them separately and lipo them together, either manually or using the muniversal PG to do it for you. Best, Ken
