Post not yet marked as solved
See if this works. Thanks.
https://gist.github.com/hecht1962/34e35e4917da2d10fb66e2c88d299b51
Post not yet marked as solved
I'm happy to share it. I tried to add it as a file enclosure, but this system doesn't seem to want to let me do that. And it's too large to paste as text.
Post not yet marked as solved
Here are straw man answers to my own questions. I'm still hoping someone can give me better answers.
Just open the binary file and read the first few bytes of it. Traipse through the cafe babes and the feed faces to find the cputype, then check it against the defined values for arm64 or x86_64. The formats are defined in <mach-o/loader.h> and <mach-o/fat.h>. Another possibility would be to do a preflight dlopen(); if it works, you know the binary contains your current architecture. But that possibility won't work for me for other reasons.
Don't use NSTask. Use posix_spawn, giving it a posix_spawn_attr that contains a posix_spawnattr_setbinpref_np, into which you can put the cputype you prefer. This is much more complex than using NSTask, and I can see why it hasn't been added to that class, but I sure wish it was. In my case, I will take the more pragmatic approach of just creating two non-fat binaries, one for each architecture. Then I can choose which one I want to launch, and do so using NSTask.
Post not yet marked as solved
To answer my own question for posterity, I did find this: ips2crash
But ultimately, I ended up writing my own with Perl.
Post not yet marked as solved
I managed to install on a thumb drive, but I'm not able to boot. I just get a gray screen with an arrow cursor. I even let it sit overnight with no change. I saw in the release notes about problems installing on an external volume. Can anyone elaborate on this?
Post not yet marked as solved
Thanks Quinn. I reviewed the linked thread and, other than a wish that there were an API to modify the DYLD search paths at runtime, I didn't see anything that would help me resolve my issue. I think the answer to my question, "Is there a way to get dyld to honor changes to DYLD_LIBRARY_PATH made at runtime?", is "No".One possible workaround that I thought of, however, would be to change DYLD_LIBRARY_PATH, then exec a child process that calls dlopen() and interacts with the library (MATLAB in this case) for me. Would that work -- would the child process get my modified DYLD_LIBRARY_PATH, or would it just use the same path as me?
Post not yet marked as solved
Thanks John. We don't distribute R with our app. But we can optionally call it if the user has downloaded and installed it. So us building our own framework is not feasible.
Post not yet marked as solved
Quinn, thanks for the research on this. Very helpful!
I found the answer.In my target's Build Settings, under Build Options > Validate Workspace - Ignored Frameworks. I add an item "OpenGL".SummaryList of framework names for which to suppress deprecation warnings and missing framework errors in the workspace validator.DeclarationVALIDATE_WORKSPACE_SKIPPED_SDK_FRAMEWORKSValue TypeString List
Post not yet marked as solved
Thanks Quinn. I have updated the bug report with the request UUIDs for both the app (which worked) and the pkg (which failed).
Post not yet marked as solved
Thanks Quinn for clarifying about needing the .pkg signed. I gathered as much after reading other responses from you on this forum.I have entered a bug -- FB7457705 -- for the errors not being treated as warnings in the package. For the record, our app is in a package, which is in a disk image. Eventually we will want to notarize the disk image. But I was trying this as an intermediate step.As for the actual problem, the libraries in question are an embedded Java 8 JRE from Azul Systems, built with the 10.8 SDKs. We do have plans to move to a more recent Java JRE. Their Java 11 JRE is built with the 10.9 SDK and their Java 12 JRE is built with the 10.13 SDK. But the architectural changes required to move to a later Java are too great for us to roll out just yet. And it is not feasible for us to wait to notarize our app until we can switch Javas.
Post not yet marked as solved
A "me too" post.As for Nilesh, my app notarizes fine but with warnings about embedded binaries using an older SDK.But if I try to notarize a .pkg containing my app, all those same warnings get turned into errors and the notarization fails.Do I actually need to notarize the .pkg, or can I simply notarize the app first then build the .pkg from that?
