Is there a way of detecting a M1 mac in MATLAB? MATLAB has ismac but that presumably won't differentiate between processor types.
New Answer: Tested on M1 Mac
My impression is that MATLAB is running through Rosetta 2, which means that the result of uname -m is actually x86_64, which does not help guard against calls to Intel targeting mex code.
Instead we'll ask for the kernel version and try to find ARM64
if ismac()
[~,result] = system('uname -v');
is_m1_mac = any(strfind(result,'ARM64'));
else
is_m1_mac = false;
end
Note result above is on my computer : Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000
Old Answer: Not correct
To detect the processor one can call to the system command line:
Detect Apple Silicon from command line
Note, this has not been tested on a m1 mac ...
if ismac()
[~,result] = system('uname -m');
is_m1_mac = strcmp(strtrim(result),'arm64');
else
is_m1_mac = false;
end
Note, this would help if you are running an older version of MATLAB, as MATLAB doesn't officially support M1 macs until 2020b update 3 ...
https://www.mathworks.com/matlabcentral/answers/641925-is-matlab-supported-on-apple-silicon-macs
However, it is not clear to me that this would eventually detect execution of MATLAB natively vs via ROSETTA (when a native option actually exists).
Related
I've got Mac OS X Sierra 10.12.3, I know that Valgrind may not be compatible with my system. I've successfully ran automake and the svn, however when I try to run make, it says:
priv/ir_opt.c:5930:14: error: explicitly assigning value of variable of type 'Int' (aka 'int') to itself [-Werror,-Wself-assign]
for (m = m; m < A_NENV; m++) {
Anyone know if this is due to compatibility with Mac OS or something else? Thanks.
As Jens suggested, I've found ir_opt.c (note for people with the same problem: be wary, as there are several ir_opt.c files, you need to edit the one in VEX/priv/ir_opt.c) and changed the m = m to m = 0, since the variable m was declared as 0 a few lines above.
Valgrind won't work on MacOS X Sierra, I have tried for a while.
I understand you got it to install with SVN, so did I, and I never even ran into this error you're having. But if you actually run valgrind --tool=memcheck --leak-check=full -v ./<program> you will find yourself running into an error.
From what I've read, this is caused by something in the OS X source code that the developers of valgrind aren't able to make modifications to their software for, because the part of OS X causing the error is under license and closed source. Or it was until recently and they haven't gotten to updating their own source code yet, or something like that.
Anyways, if you want to use valgrind on OS X you'll have to install a virtual machine with linux on it. I'm using VirtualBox with lubuntu and I'm sharing my home folder to the VM, and I'm not having any problems running memchecks that way. Any distro should be fine, but IMO the lighter the better.
If for some reason it actually does work for you with valgrind memchecks, then I guess you're just lucky. I'd still suggest you switch to using a linux VM anyways, because there is no guarantee that valgrind will function fully on OS X and it may not catch everything like it's supposed to.
I'm a beginner of HTK (Hidden Markov Model Toolkit).
I just compiled and installed it on my Mac machine (MacOS Sierra).
When I run a HSLab command like:
HSLab no_name
it opens a GUI window properly. But when I click "rec" it crashes with:
ERROR [+6015] StartAudioInput: null audio device
FATAL ERROR - Terminating program HSLab
The HTK version is 3.4.1 (current stable).
Any ideas?
I can produce the same error on my Linux machine (openSUSE Leap 42.2) running Pulseaudio sound manager. The fix for me is to prefix the command with padsp as in:
padsp HSLab no_name
Then the rec button works correctly. I'm not sure the audio recorded is what is required, but that is another issue. No doubt one day we will be able to compile HTK to be PA aware.
I seem to have a problem with Yosemite compiling.
I Have downloaded
dtrace-118.1
AvailabilityVersions-9
xnu-2782.1.97
It seems like the command line tools are not installed but a previous kernel version works, I replaced the makedefs folder from the previous kernel and well it starts compiling but of course fails.
The error I have is here:
[removed]
I had the same issue. It's because the new kernel uses the macosx.internal SDK to compile by default which obviously isn't available because it's Apples internal SDK. If you use the standard macosx SDK it'll compile fine. I used:
make TARGET_CONFIGS="RELEASE X86_64 NONE" SDKROOT=macosx
And I'm currently running the kernel without any issues on my late 2009 MacBook. If you have a Haswell CPU then change the arch type to "X86_64H".
Also while I'm on the topic I noticed there's a couple of new platforms listed under SUPPORTED_PLATFORMS in makedefs/MakeInc.def. iPhoneOSNano and iPhoneNanoSimulator. I'm guessing they're for the Apple Watch. None of the actual code is available but it's mentioned in some makefiles.
Fixed, problem in the xnu-2782.1.97/makedefs -> MakeInc.cmd Line 37 SDKROOT ?= macosx.internal Replace SDKROOT ?= / –
The instructions found at Setting Up Kernel Debugging are what I used to get to this point. On the machine running the kext I want to debug, I do see the message "Connected to remote debugger". On the machine I am running gdb on, I do see:
(gdb) kdp-reattach localhost
Connected.
The problem is that 'showallkmods' returns an empty list and none of the other similar commands appear to be working:
(gdb) showallkmods
kmod address size id refs version name
(gdb) showalltasks
task vm_map ipc_space #acts pid process io_policy wq_state command
Invalid type combination in equality test.
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) source /Volumes/KernelDebugKit/kgmacros
Loading Kernel GDB Macros package. Type "help kgm" for more info.
(gdb) showallkmods
kmod address size id refs version name
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) showbootargs
Invalid cast.
I am running 10.6.8 and am using kernel_debug_kit_10.6.8_10k540.dmg
I am not sure what other details one might need to diagnose what has gone wrong, but if you want to ask questions in the comments, I can certainly attempt to provide additional details.
The error "Invalid type combination in equality test." indicates to me that gdb might be expecting a different CPU architecture than the kernel you're connecting to is running. The 10.6 kernel exists in both 32-bit and 64-bit variants, and by default it's determined by the hardware which one gets loaded. gdb normally defaults to x86_64 if your CPU supports it (true of all Intel Macs except the very early Core Duo based ones) so if you're connecting to a 32-bit kernel (the default on most Macs released before 2011) you need to pass the -arch i386 argument when starting gdb. You can check the current kernel CPU architecture by running the uname -a command.
Update: on OSX Mountain Lion, the kernel always runs in 64-bit (x86_64) mode. On OSX Lion, the kernel defaults to 64-bit mode on Macs which are capable of running Mountain Lion and in 32-bit mode otherwise.
I have a unix command line app (with big nasty makefile) that I'm trying to run on a mac. I am compiling it on a 10.6 system, with all of the appropriate libraries of course. The deployment environment is a 10.5 system, with no extra libraries.
I compiled without -dynamic, and it appears to have static libraries, correctly. When I run it on the 10.6 system, it works. However, when I run it on the 10.5 system, I get:
dyld: unknown required load command 0x80000022
I got this same error when I compiled things for the 10.6 system using the 10.5 xcode, so it looks like a version mis-match type problem. However, I used gcc-4.0, and
$CFLAGS = -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
so it SHOULD be set up for 10.5... any ideas?
thanks
Editing an ancient question:
I have the exact same problem on a different computer. This time I am at 10.5.8, fully update, the same executable works on 10.6 still.
Has anyone had any luck with this in the months since I asked this?
The reason for the dyld 0×80000022 error can be that, you are linking on OS X 10.6, and OS X 10.6 will use a load command (LC_DYLD_INFO_ONLY = 0×80000022) that OS X 10.5 does not understand.
To fix this, make sure you are using a deployment target by setting the environment variable just before your link command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
You can always check if your executable uses the right load command like this:
otool -l executable
It will either show LC_DYLD_INFO_ONLY (without deployment target) commands or LC_DYLD_INFO (with deployment target).
I have been searching for the same issue, as I develop on 10.6 but must have a version that works on 10.5. In addition to the compiler flags above, you should add:
-no_compact_linkedit
It is described here:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html
where it says:
Normally when targeting Mac OS X 10.6, the linker will generate compact information in the __LINKEDIT segment. This option causes the linker to instead produce traditional relocation information.
I got there from a discussion on the xcode-users mailing list about "unknown required load command 0x80000022".
i was able to solve this by passing -mmacosx-version-min=10.5 to the linker, e.g. --extra-ldflags="-mmacosx-version-min=10.5" passed to configure for ffmpeg which i was building shared. more info: http://lists.apple.com/archives/xcode-users/2009/Oct/msg00530.html
Depending on how many libraries you use, it may be difficult to get all of them linked statically. What does "otool -L your_binary' tell you?
In order to get a self-contained package for an application of my own, I made a custom MacPorts install in a non-standard directory, so that I could dynlink with the libraries from that directory and only be constrained in asking people to install the whole thing in the same place on their computers. Not great, not the Mac spirit at all, but it's an Unix app and you need to be familiar with Unix to use it anyway.
Good luck
Pascal
It turns out that there is a dynamic library load function (0x22) that got added at 10.5.6. The system I was running on was 10.5.5. I upgraded to 10.5.8, and everything runs!
Ok, SECOND solution, and NOT very satisfying, is to find a 10.5.8 computer, install the developer packages and re-compile... same for powerPC... sad but it will work...