Thanks for that. Learned something new, that is really old.
otool has -arch support in it.
so you can examine different parts of your universal binary like this:
otool -l -arch arm64
otool -l arch x86_64
which is totally obvious in retrospect, but I just never thought of
doing it before....
Ken
On 2021-03-31 6:10 a.m., Sandeep Thakkar wrote:
Hi,
I installed postgresql13 the same way. I then copied the files to
macOS Catalina and here is the output:
*on macOS Big Sur arm64:*
% sw_vers | grep ProductVersion
ProductVersion: 11.0.1
% otool -l /opt/local/lib/postgresql13/libpq.dylib| grep minos
minos 11.0
% md5 /opt/local/lib/postgresql13/libpq.dylib
MD5 (/opt/local/lib/postgresql13/libpq.dylib) =
b0bae706c59a99ddbb40bb6fe3e3ea66
*on macOS Catalina x86_64:*
$ sw_vers | grep ProductVersion
ProductVersion: 10.15.7
$ md5 /tmp/opt/local/lib/postgresql13/libpq.dylib
MD5 (/tmp/opt/local/lib/postgresql13/libpq.dylib) =
b0bae706c59a99ddbb40bb6fe3e3ea66
$ otool -l /tmp/opt/local/lib/postgresql13/libpq.dylib | grep minos
minos 10.14
So, it seems the build is fine. The otool is correctly returning the
macosx-version-min for that Arch which seems fine.
Thank you for your responses and sorry for the noise.
On Wed, Mar 31, 2021 at 12:30 AM Ken Cunningham
<ken.cunningham.web...@gmail.com
<mailto:ken.cunningham.web...@gmail.com>> wrote:
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
--
Sandeep Thakkar
