Most parts of our application are built using CMake because they are cross-platform. Now, I know I can set CMAKE_OSX_ARCHITECTURES to build a a fat binary, and it works fine for our smaller, self-contained components. However, some components use optimized third-party libraries that are architecture specific. There's really two cases here:
The library interface is standard (e.g., BLAS) and we're just using a different library to provide the implementation.
Our own code path depends on the library, in which case we pass in a define (using target_compile_definitions) know which code to use.
Is there a way to make the linker libraries or compile definitions depend on the target architecture? For the first case, I might try listing both and hoping only the needed slice from each one is used (though that presuppose either that they each only have one slice, or that the single-slice one comes first). But in the second case, I really don't see how to do this, short of having two separate thin targets that are manually lipo'd together.
Post
Replies
Boosts
Views
Activity
Up until now, we have been using an optimized BLAS library for Intel processors. Now we are looking for replacements for Apple Silicon. I know that Accelerate provides such an interface. However, I haven't been able to find if it provides an ILP64, rather than LP64, interface, which is what we use on all 64-bit platforms. If it does, how do I access it? Thanks.
In Big Sur, I noticed that the open command no longer distinguishes different copies of an application. For example, if I have /Applications/AppV1.app and /AppicationsAppV2.app, and AppV1.app is running, then open /Applications/AppV2.app is simply bring AppV1.app rather than opening AppV2.ap. I have to use the -n flag to open the second version. This seemed like a regression to me (I filed FB8806330 about it), but perhaps intentional, or at least justifiable.
But now I've discovered a much worse symptom. If App.app and Bpp.app is another application by my company, then open /Applications/Bpp.app brings App.app to the foreground rather than opening Bpp.app. All the applications have distinct bundle identifiers. Indeed open -b com.Company.Bpp will also bring App.app to the foreground.
This is just a crazy bug, right?
Any ideas what it might be keying off? It can certainly tell the difference between our apps and, say, Safari. So I'm not sure why it can't tell our applications apart.
And if anyone from Apple is here, should I add this worse symptom to my existing FB, or open a new one?
Thanks
I guess this question is rather meta, because I'm at least as interested in knowing how to get help as in some actual help.
Anyway, we use LDAP and NFS to provide shared home directories for folk across machines, and enable screen sharing (maybe Remote Admin? I sometimes get these slightly confused) on networked Macs.
Apparently, since Catalina, we have had issues where VNC logins from LDAP users hang (I think pretty reliably, but I'd have the check the notes from sysadmin). Afterwards, random things start to hang for other users (whether connected via VNC or SSH), until you have to reboot to do anything useful with the machine.
If only local accounts use VNC while LDAP users use SSH, things are fine, except that a terminal it is not necessarily the best way to develop.
This has become an issue as were setting up M1 Macs to expand the effort beyond the initial core team that worked on the DTK (which had local accounts only, obviously).
So, first question, do these symptoms sound familiar to anyone? Any troubleshooting suggestions?
Second, where could we get some actual support? Is this something we can use DTS ticket on? It's not really related to our development as such, but it sure is blocking our development work. And given the currently level of "Geniuses" (unlike 15 years ago, when you really could find someone to talk to at a store), I don't think asking one of them this question would be helpful. I'm not sure what other avenues there are. Any help would be appreciated.
I have always believed (perhaps becomes I am an old-timer working on OS X since before these i-things came along), that while frameworks on iOS are flat, frameworks on macOS are always versioned. In particular, they have a Versions directory, and any siblings of Versions are symlinks to Versions/Current/sibling.
However, having just downloaded a thirty-party framework that we bundle, it is flat. There is no Versions directory, and at everything at top level is a real file and not a symlink. This has caused our code for resigning as needed to fall over because it expects a Versions directory.
Obviously, we can can update our code to deal with a flat framework (or, I suppose, de-flatten the framework if we want). But before I do, is such a structure officially supported? I've never seen it before, so I wanted some confirmation, and some Googling didn't find any references to unversioned frameworks on macOS.
Things like vm.pagesize and vm_page_size return the page size of the running architecture. However, we need to know the true page size, so that, e.g., a Rosetta process will allocate enough memory to be mmaped by an ARM process (we use shared memory, among other methods, for IPC). I see in vm_page_size.h a vm_kernel_page_size. Is that the correct way to ask for the "hardware" page size?
If you execute python3 and it is not pointing to an active developer tools, the user is prompted to install the command-line tools. Is there a way to test if python3 is actually available without triggering installation?
(Our use case is that we would like to enumerate available python installs for the user to select from, without this accidentally triggering an install.)
In Monterey, if your application executes python or python2.7, you will get a warning dialog that the python2 will be removed. However, this seems to happen only once. How can we reset the warning to make sure we're not accidentally triggering this on Monterey/
Is there a way in pure C (not Objective-C, and certainly not Swift) way to detect if an iOS app is running on a Mac? I'm aware of iOSAppOnMac, but AFAICT I'd need to write Objective-C code to use it. My application is quite old and large, with portions going back to the 1980s, so the burden of moving on the anything that can't be accessible directly from C is quite high.