-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iaito_5.9.2_m1.dmg is not working #170
Comments
The name of the release is also a bit confusing (unless this means it only supports m1 and no other chips). |
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
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 : even though I had qt@5 which seems to be installed :
And exported to path via :
Double-clicking on the TLDR : |
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. |
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. EnviromentChip: Apple M3 Max Make a working appI 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.
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:
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 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 This makes it essentially impossible to run (or build) currently, as it cannot find any of the required libraries. |
What would you suggest to do? |
I would say, in every case where The easiest fix however, would just be to swap out |
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.
Currently the official dmg build is intended work with the official radare2 build (the 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. Since there are no homebrew formula of radare2 nor iaito I don't see any need to use @tanis2000,@SoCuul: Regarding detecting radare2 installation or any compilation problems using the default 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
|
@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 |
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? Thanks in advance |
@prodrigestivill @SoCuul symlinking libraries from 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? Iaito dmg is not using homebrew prefix nor usr/local prefix to install anything. Having said that, I belive we must not use the 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 This was about the install path, but I undestand that here we are talking about dyld serch path that iaito has set. So changing this means changing it at least in radare2 and r2pm default paths for mac to, for example, 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. |
@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:
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:
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. |
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. |
I would also like to add that the prooper xattr command is: |
As far as I know next iaito version will fix those things:
Also once we have this new release we plan to try to ask to add iaito to homebrew, but as of now iaito is not there :(. Regarding updating the xattr command, can you please create a PR to update this file |
#209 goes against the core homebrew packaging philosophy. Binaries should be distributed as formulae, and Applications as casks. When defining the cask, you can mark a formulae (eg. radare2) as a dependency, and it will be installed alongside the cask. However, this does mean that you have to fix the behaviour of this app only checking |
@SoCuul I believe there is no need to get this confrontational, this issue has been taken care of, and we dedicated a lot of our free time to fullfill your requirements aiming also not to break what other users have. What I have read their guidelines to submit Applications says that they dont want us to point to a dmg for homebrew only, they want to use the same dmg intended to use outside homebrew. This toghther with that homebrew don't allow formulae1 for Applications and having iaito binaries require the specific radare2 version on which it has been linked against. Note that right now you must have the exact same radare2 version on which iaito has been build against in order to be able to launch iaito dmg from releases. All toghether means that we don't want to use the one outside since all updates will break iaito because releases of radare2 and iaito aren't sync while there aren't any restriction on building. Regarding the second part, there is no need to have none of that paths you mentioned if radare2 is embded inside the dmg. Footnotes
|
Apologies if it came off confrontational, could have phrased it much more constructively. Upon further inspection, homebrew will not allow unsigned apps to be added to the casks repository. As an alternative you can host your own tap in this (or another) repository. This gives the added benefit of not having to follow their packaging guidelines, allowing you to distribute whatever you want in whichever form. |
Thank you for bringing up the signing issue, we had this in mind some time ago, not sure what has been decided. Also nice proposal to create our own tap repo, we will evaluate it too. |
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 text was updated successfully, but these errors were encountered: