Issue with Mac OS Catalina

[urklang]

Great! I'll try to figure out what the real solution for this is so we can get it into future patcher releases.

Did OS X actually complain about liblto_plugin.so (a linked library)? It might be enough to authorize only the executables.

[tele_player]

From the standpoint of security, .so files are executables.

[urklang]

Sure. I would just be surprised if a user facing security mechanism would actually report at that level of granularity rather than blocking the executable being invoked, maybe it does really check on every linked library. That's what I'm asking about. Any idea what specifically is pulling in that library? I'm still interested in getting the complete list of files in platform_osx from your machine.

Edit: ok, interesting. For future reference, liblto_plugin.so is out in platform_osx/lib/gcc/arm-none-eabi/4.9.3, part of the arm toolchain that gets pulled in. I'm still curious if it prompted you on this or not. The virtual machine OS X I have available is still on Mojave.

[donaldhamby]

Ran ls -lat on the platform_osx/bin directory, here's what it gave me

[tele_player]

That looks like /Applications/axoloti_runtime/platform_osx, NOT /Applications/axoloti_runtime/platform_osx/bin.

[donaldhamby]

OK, try this:

[urklang]

Nothing looks abnormal here. Did you intentionally try to authorize everything in platform_osx ahead of time or did you just authorize one by one as OS X prompted you? I'm curious about the exact list of what it flagged and in what order it happened. I'll be able to reproduce on a Catalina VM eventually, but it would help me out to know what you saw.

[donaldhamby]

Just one by one as prompted, but unfortunately I didn't take note of what needed to be authorised

Perhaps if someone else goes through this process they can post a list here?

[urklang]

Ok, cool. I'll look for an automatic solution but in the meantime we should try to simplify the workaround. I'm wondering if there's a shorthand in Catalina for "Authorize everything under this directory" so we can avoid stepping through each file.

[thetechnobear]

ouch... Ive not installed Catalina yet (*)

quick thoughts...
the runtime is basically just a copy of build tools used for cross platform development, so why is this issue not 'all over the internet' ... surely developers are already running these tools. and Ive not seen discussion from them on authorising all these 'utilities' - and how are things like home-brew working?
(so my suspicion is auth individual binaries is not the solution... )

perhaps it's a 'downloaded' application cannot run non-auth executables, but even there, things like eclipse do this, perhaps all developers have disabled gatekeeper? (seems unlikely)

id be surprised if Xcode-select helps, as its not going to just be make - its going to need to them spawn (from make)the compiler (arm-none-eabi-gcc).

@donaldhamby
if you to run in the terminal... do they work, or do you get same error?

/Applications/axoloti_runtime/platform_osx/bin/arm-none-eabi-gcc
/Applications/axoloti_runtime/platform_osx/bin/make

hmm, more questions that answers , until I can run Catalina.

one idea. I wonder if apple differentiates system software to apps.

I would like to try the following

sudo mv /Applications/axoloti_runtime /usr/local

then in Axoloti->preferences , change runtime dir to /usr/local/axoloti_runtime

then try to compile a patch. (you might need to restart axoloti, not sure )

if thats not working again running individual commands from the terminal might be enlightening.

/usr/local/axoloti_runtime/platform_osx/bin/arm-none-eabi-gcc
/usr/local//axoloti_runtime/platform_osx/bin/make

note:
if it doesn't work you can reverse using:

sudo mv  /usr/local/axoloti_runtime /Applications

apart from that, I think Id need to install Catalina to see whats possible.....and how to work around things.
(in particular, Id like to isolate the cause of the issue a little better)

---

(*) Ive some hardware that doesnt work on it, so I was waiting on them to fix it. so, chicken n' egg , Ive not been able fix/verify software I work on, due to others not having their software fixed
don't have enough spare macs to dedicate one to this, nor enough space to create a VM - arghh

[thetechnobear]

@donaldhamby
Another thing to try :
Preferences-> privacy/security
Full disk access

Add axoloti to this

Restart axoloti.

Note : please try one thing at a time, so if it’s fixed we know what cured it
... so revert any other ‘tests’ you do before trying new test.

[urklang]

Here's an interesting potential workaround that might be shorter (from https://www.reddit.com/r/MacOS/comments/c68gh9/solution_for_all_apps_not_opening_in_catalina/):

sudo spctl --master-disable

Run axoloti and go live on a patch.

sudo spctl --master-enable

Supposedly what is done in the interim there will remain authorized after security is re-enabled. Again, I don't have a Catalina system handy to test on yet so post your experience if you try this on a fresh install.

[donaldhamby]

Thank you for all the suggestions!

If I get time this weekend, I'll reinstall Axoloti, try them out and report back

[dianus]

On OSX Catalina, this fix worked for me. Thanks @urklang!

[Woodinblack]

I hadn't read this thread and I updated my mac to Catalina at the weekend. I tried running the axoloti and I got the box at the start of this thread, but I fixed it the slow way, like someone said up there.
Run the patch, it complains it can't run make. Go to System Preferences -> Security and Privacy and there is a box that says 'we blocked 'make', press allow to unblock this app'. Click allow, run the patch again, it asks if you want to open make, say yes, then it complains about the next thing. Went through that 7 or 8 times, and all was done.

Wish I had read the thread though!

[blackmountain]

Not sure what the situation is with Catalina, but I can't seem to locate a subpatch I've created.

When I open the object selector typing ./ gives me no results even though the subpatch is in the same MacOS folder

Could this be a different problem or is it a Catalina issue?

[lokki]

are you sure you actually saved the subpatch as such? or did you simply embed it in the main patch? if the latter is true or will only be saved as part of the main patch

[blackmountain]

I think I’ve sussed out the problem I was probably doing a couple of things incorrectly. 1) I had not saved the main patch before trying to add the object, so not sure if the context was the right root directory. 2) I did not type in the whole name of the subpatch before the .axs extension. I though there was matching on part of each filename as if I type in ‘os’ I get objects such as /osc/sine but with my subpatch nothing was appearing in the search results, presumably because the root directory is not in the library path.

[sethhunter]

This works for me on Catalina - it was the first thing I tried and solved my issues. Note I have the latest public release.