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
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
> 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
The same behaviour with llvm-11
On Tue, Mar 30, 2021 at 5:10 PM Chris Jones
wrote:
> Hi,
>
> Llvm/clang 10 does not work reliably on apple silicon. use llvm/clang 11
> instead.
>
> Chris
>
> On 30 Mar 2021, at 7:19 am, Sandeep Thakkar <
> sandeep.thak...@enterprisedb.com> wrote:
>
>
> Hi,
>
>
Hi,
Llvm/clang 10 does not work reliably on apple silicon. use llvm/clang 11
instead.
Chris
> On 30 Mar 2021, at 7:19 am, Sandeep Thakkar
> wrote:
>
>
> Hi,
>
> I'm installing llvm-10 on Apple M1 (macOS BigSur) with these changes in
> macports.conf:
>
> # custom changes
>
Hi,
I'm installing llvm-10 on Apple M1 (macOS BigSur) with these changes in
macports.conf:
*# custom changesbuildfromsourcealwaysmacosx_deployment_target
10.14macosx_sdk_version11.1*
and the command I used is:
*% sudo port install llvm-10 +universal*
But, what I see is:
*% otool -l
