radareorg
iaito_5.9.2_m1.dmg is not working
Environment
Chip : Apple m2 pro OS : Sonoma 14.0
Description
I downloaded iaito_5.9.2_m1.dmg
On opening the downloaded .dmg file, i got :
The name of the release is also a bit confusing (unless this means it only supports m1 and no other chips).
Maybe name it iaito_5.9.2_arm64.dmg, or even iaito_5.9.2_apple_silicon.dmg ?
Works for me. Do you have r2 installed? Try running it from the shell and see whats the error
On Iaito 5.9.2 releases notes, there's :
Build from Source
curl -sL https://github.com/radareorg/iaito/releases/download/5.9.2/5.9.2.tar.gz | tar xzv
iaito-5.9.2/sys/install.sh
But https://github.com/radareorg/iaito/releases/download/5.9.2/5.9.2.tar.gz does not seem to exist.
Here's what I tried :
git clone https://github.com/radareorg/iaito.git
cd iaito
./configure
make
the end of the build indicates :
ld: warning: search path '/usr/local/opt/qt@5/lib' not found
even though I had qt@5 which seems to be installed :
brew install qt@5
[...]
Warning: qt@5 5.15.13_1 is already installed and up-to-date.
And exported to path via : echo 'export PATH="/opt/homebrew/opt/qt@5/bin:$PATH"' >> ~/.profile
Anyway,
executing make run successfully launched Iaito, but the .dmg that was downloaded from the 5.9.2 release and mounted still had an issue (interesting enough, with a different error message):
open /Volumes/iaito/iaito.app
The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10661 "(null)" UserInfo={_LSLine=4106, _LSFunction=_LSOpenStuffCallLocal}
Double-clicking on the .dmg made the following pop up :
TLDR :
It works via the Makefile, but still not via the .dmg
The 5.9.2._m1.dmg can be unzipped and installed to my /Application/ folder.
But when I open it, it will crash due to some signature issue.
Env: macOS 14.5 (23F79)
Here is the script I use to re-codesign everything to workaround it.
#!/bin/bash
APP_PATH="/Applications/iaito.app"
IDENTITY="-" # Replace "-" with your actual identity if needed
# Sign all the nested frameworks, libraries, and executables
find "$APP_PATH" -type f \( -name "*.dylib" -or -name "*.so" -or -name "*.framework" -or -perm +111 \) -exec codesign --deep --force --options=runtime --sign "$IDENTITY" {} \;
# Sign the main application bundle
codesign --deep --force --options=runtime --sign "$IDENTITY" "$APP_PATH"
Any idea how to run this script in the ci? I will probably need to push my key somewhere but its not clear to me the way to go
Any idea how to run this script in the ci? I will probably need to push my key somewhere but its not clear to me the way to go
You can use GitHub secret to upload your p12 keychain. And then import it to your workflow.
Some article I found on the Internet may help you here.
- https://localazy.com/blog/how-to-automatically-sign-macos-apps-using-github-actions
Any idea how to run this script in the ci?
BTW, What do you mean of running the script in the CI?
It is intended to be a temporary local re code sign solution to fix the upstream releasing bug.
If you are the author of the app and is working on a fix to it, there is probably some easier way to do it. (Properly code signing it right after building)
Thanks for pointing out the links, yes i'm the only maintainer and developer here, just busy so i appreciate you pointing to the link.i'll try to setup the proper signing in the CI before cutting a new release
Thanks @a-levra! I had this same issue with iaito 5.9.4.
Enviroment
Chip: Apple M3 Max OS: Sonoma 14.6.1
Make a working app
I was able to get a working app by using the makefile in the macos folder.
For anyone that just wants the app file, run this instead.
git clone https://github.com/radareorg/iaito.git
cd iaito/dist/macos
make app
It will make a zip file in the macos folder with the app in it. Then just move the app to the applications folder.
My solution is to re-sign：
$ xattr -rc /Applications/iaito.app
$ codesign --force --deep --sign - /Applications/iaito.app
@ac0d3r your solution works for me, so ive updated the readme in the release page to share those instructions. The only thing i changed is that xattr -r doesnt exist. But just doing -c is enough to work for me.
Even replacing the signature does not make it work for me. It does seem to start but then it crashes with the following error:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace DYLD, Code 1 Library missing
Library not loaded: /usr/local/lib/libr_reg.dylib
Referenced from: <EBA85510-AC4A-379A-9B72-169A792DAF24> /Applications/iaito.app/Contents/Frameworks/libr_egg.dylib
Reason: tried: '/usr/local/lib/libr_reg.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/lib/libr_reg.dylib' (no such file), '/usr/local/lib/libr_reg.dylib' (no such file)
(terminated at launch; ignore backtrace)
I can't understand why it is not looking into its own Framework folder, though... libr_reg.dylib is inside there.
You need to install r2 separately
I do have r2 installed separately, but on Apple Silicon the path to shared libraries installed with homebrew is not /usr/local/lib but /opt/homebrew/lib.
You should not hardcode the path of shared libraries as it is different between x64 and ARM.
@trufae in /src/Iaito.pro you're hardcoding the library paths to /usr/local which is extremely problematic, as libraries are installed to /opt/homebrew on apple silicon machines.
This makes it essentially impossible to run (or build) currently, as it cannot find any of the required libraries.
I would say, in every case where /usr/local is hardcoded, it should check for the existence of /usr/local and /opt/homebrew and pick the "better" option based on the current architecture, falling back to the other if errored.
The easiest fix however, would just be to swap out /usr/local with /opt/homebrew if the CPU architecture is darwin arm64. In this case, an override via a make flag (or something of that sort) could be useful as well to bypass the architecture-based directory selection, and force your own path that the binaries are installed to.
That would be a problem for everyone installing r2 from source. Like me for example. Maybe a shellscript wrapping some env vars may be a better solution and avoid hardcoding any path?
Yeah, that would probably be the best solution. Search through multiple paths (usrlocalbin/opthomebrew) and find the best one (or use one explicitly provided by the user).
can you submit a PR with the fix and try it in your environment? im a little busy in so many other fronts right now and i will probably take more time to go there. maybe @prodrigestivill can take a look too. thanks!
hopefully that should be the last frontier before closing this ticket
For what I understand there are 3 things here.
-
Signing the macos binary: a. Uploading the signing key to GitHub Actions Secrets and sign the mac app on each release. b. Update the main project README or releases notes to include the process. c. Append a README file in the DMG to (similar to https://github.com/SuperDude88/TWWHD-Randomizer/commit/2a3cc1096ee176e35ce46061215e561f0342ffea).
-
Renaming the dmg names from
m1toarm64This can be done easily if it causes some confusion. (radareorg/radare2#23845, #206) -
Homebrew installation paths
Currently the official dmg build is intended work with the official radare2 build (the .pkg file from their releases page) and both use /usr/local prefix for both architectures.
This path is configurable at build time and currently is working in the CI on both architectures.
Homebrew team have decided some time ago to split the prefix depending on the platform in order to be able to mix x64 and arm64 installs in the same machine.
So both paths can get used on arm64 machines by homebrew, but also /usr/local is used by other official packages (like docker or rancher desktop, etc...).
Since there are no homebrew formula of radare2 nor iaito I don't see any need to use /opt/homebrew as a prefix for those installs since I believe it should be restricted their usage for homebrew managed apps.
@tanis2000,@SoCuul: Regarding detecting radare2 installation or any compilation problems using the default /usr/local prefix, can you please detail more what errors do you find? is it trying to load the x64 version of a library instead of the arm64?
This path should only be used to locate radare2 libraries as an extra place to lookup. This is because for mac builds since 2023 dyld will not look for libraries into any folder by default unless specified as rpath or DYLD_FALLBACK_LIBRARY_PATH env var, as exposed in their man page:
For new binaries (Fall 2023 or later) there is no default. For older binaries, there is a default fallback search path of: /usr/local/lib:/usr/lib.
@prodrigestivill I can't say whether it is trying to load the x64 version of the libraries or if it is just that someone set the arm64 path to the same location as the x64 ones. What I can tell you for sure is that it tries to look into /usr/local/lib on an Apple Silicon (armn64) box, while it should actually look for the arm64 ones in /opt/homebrew/lib which is the default path that homebrew adopted for arm64 libraries.
I agree with @tanis2000. A possible workaround is to symlink each binary to /usr/local/lib, but that's not a reasonable solution for most users. A good 90% of macOS developers will be using homebrew as their package manager, and not being compatible with apple silicon macs using hb is affecting (and will increasily affect) developers.
@SoCuul I don't follow the issue you are comenting...
Can you detail what binaries are you proposing to symlink to /usr/local/lib as a workarround? Maybe with this infromation I can follow you better.
Thanks in advance
@prodrigestivill @SoCuul symlinking libraries from opt/homebrew/lib to /usr/local/lib is not really an option. It's a quite ugly workaround. The best option is to set the correct path to look for libraries based on the architecture the application has been compiled for.
I am not familiar with this code-base, but it's something trivial with CMake and similar build systems.
@tanis2000 can you clarify me what libraries are you talking about? this was my previous question, and I belive the answer will help me undestand better your point of view.
Iaito dmg is not using homebrew prefix nor usr/local prefix to install anything.
Having said that, I belive we must not use the /opt/homebrew path since for my interpretation this is clearly reseverd for packages installed using their package system, and the pkg files generated in radareorg/radare2 aren't in integrated with brew.
If this prefix was about the architecture, homebrew team wouldn't have named like that, so to me that path it's clearly reserved for their use only, and using it might corrupt brew installs and most provably is why they decided to change it from local in the first place.
So, alternatively, I can undestant a proposal use /opt/radare2 instead of /usr/local as its default installation path from the pkg, following the same spirit as homebrew team. But this would need to be changed into the rest of radareorg projects, since iaito insn't installing anything there.
This was about the install path, but I undestand that here we are talking about dyld serch path that iaito has set.
This path is in the build files because radare2 and r2pm (radare2 package manager) installs have /usr/local install prefix path by default on mac.
So it means iaito needs to look there for libraries too in order to ensure all the plugins work.
So changing this means changing it at least in radare2 and r2pm default paths for mac to, for example, /opt/radare2.
But the question I still don't undestant is why this is an issue?
Again, my M3 mac has a lot of arm64 files installed in /usr/local. And some come from brew indirectly, since some casks install files there on launch (docker, rancher,...).
@prodrigestivill I am not saying that you should install Iaito somewhere else than where it is (btw it lives in /Applications just like all apps on macOS and it self-contained, so all good).
What I am saying is that the Iaito binary is loading some dynamic libraries and those dynamic libraries are in /opt/homebrew/lib by default on Apple Silicon devices.
If you look at the crashlog I posted, you can see the following:
Termination Reason: Namespace DYLD, Code 1 Library missing
Library not loaded: /usr/local/lib/libr_reg.dylib
Referenced from: <EBA85510-AC4A-379A-9B72-169A792DAF24> /Applications/iaito.app/Contents/Frameworks/libr_egg.dylib
Reason: tried: '/usr/local/lib/libr_reg.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/lib/libr_reg.dylib' (no such file), '/usr/local/lib/libr_reg.dylib' (no such file)
Iaito is compiled to load dynamic libraries from the paths you see above. Which is fine for x64 versions of macOS but it is not for arm64c versions.
As an example, libr_reg.dylib is here on my system:
➜ ~ ls -al /opt/homebrew/lib/libr_reg.dylib
lrwxr-xr-x 1 tanis admin 42 Dec 27 10:57 /opt/homebrew/lib/libr_reg.dylib -> ../Cellar/radare2/5.9.8/lib/libr_reg.dylib
which is the standard place for radare2 libraries when you install radare2 using homebrew, which is quite common.
The easy and clean solution would be to add /opt/homebrew/lib to the list of paths to look for dynamic libraries. Is this explanation better?
yes, now I follow your point, thanks for the clarification.
So I undestand that the issue is when using iaito from dmg with homebrew installation of radare2.
Again, the iaito dmg from releases is build to be compatible with the pkg from radare2 relases page.
So I undestand that you are asking to make it compatible with the homebrew installation too, or maybe makes more sense to have a homebrew formulae for iaito that set those paths, so that brew users will install both using their install prefix.
So any update to this? I would like to use iaito but find it really silly that the only way to do so on an Apple Silicon mac is to either be forced to use the x86 release or the m1 (odd name) release myself. You could also just release a universal binary and make changes needed to account for homebrew installs, like every other app on the internet.
Again, the iaito dmg from releases is build to be compatible with the pkg from radare2 relases page.
This is kind of an odd stance to take here. Why is radare2 on homebrew then? Is this not the "official" GUI for radare2? There is zero reason as to why this application cannot make a few lines of changes to support official releases of radare2.