Skip to content
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

New package: r2ghidra-dec-4.5.0 #24453

Closed
wants to merge 1 commit into from
Closed

New package: r2ghidra-dec-4.5.0 #24453

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Aug 24, 2020

See Issue for Cutter but it is instead packaged seperate, like arch does it (PKGBUILD).
The 11-pkglint-elf-in-usrshare.sh post-install hook fails, but radare2 expects plugins in /usr/share/radare2/plugins and Cutter expects them in /usr/share/RadareOrg/Cutter/plugins, with the only alternative being ~/.local, as far as I'm aware.

Comment on lines 17 to 31
do_fetch() {
git clone --depth 1 --branch v${version} https://github.com/radareorg/r2ghidra-dec.git ${wrksrc}
git clone --depth 1 --branch v${_cutterversion} https://github.com/radareorg/cutter.git ${wrksrc}/cutter
cd ${wrksrc}
git submodule init
git submodule update --recursive
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a good solution. The build can change if they make updates to the branch. You should fetch all the files, including submodules, by adding a definitive file to distfiles. So either a tag or specific commit.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

@ericonr
Copy link
Member

ericonr commented Aug 24, 2020

Once #23601 is merged, you can use it.

@ghost
Copy link
Author

ghost commented Aug 24, 2020

Once #23601 is merged, you can use it.

I just noticed Arch just moves them to lib in their PKGBUILD mv "${pkgdir}"/usr/share/radare2/plugins/*.so -t "${pkgdir}/usr/lib/radare2/${r2version}". Should I still wait for #23601 or just move too?

@ericonr
Copy link
Member

ericonr commented Aug 24, 2020

I guess it depends. If the program works fine with the files there, it should be fine to move. Not sure what's preferred, though.

@ghost
Copy link
Author

ghost commented Aug 24, 2020

I'll try if it works with moving. Also just fixed the listing in distfiles and checksum

@ericonr
Copy link
Member

ericonr commented Aug 24, 2020

Out of curitosity, any reason this can't be built into the ghidra template?

@ghost
Copy link
Author

ghost commented Aug 24, 2020

This is only the decompiler part of ghidra, which is portable and written in C++ while the rest of ghidra is written in Java. People who want to use ghidra's decompiler in radare2/cutter don't necessarily want the entire ghidra installed, and people who want to install ghidra don't necessarily want the radare2/cutter plugins installed.

@ghost
Copy link
Author

ghost commented Aug 24, 2020

Arch only moves the radare2 plugin .so and not the Cutter one. I couldn't get Cutter to load the plugin when I placed it in lib, so I guess this will have to wait for #23601 to be merged.

@ghost
Copy link
Author

ghost commented Aug 26, 2020

xlint should be updated for ignore_elf_files, but the package works now. Please review

f94d81919bddc5f1095250e02b1fdf57acba15e68c818d6c33088875e6759d21
cad9cf37ec54bb98b40afc03cd5e2fdc78682fe0f235fd02c575d9b4d9443b83"

pre_configure() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

post_extract() is better.

pkgname=r2ghidra-dec
version=4.5.0
revision=1
archs="x86_64"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really only for x86_64, or is it nocross?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ghidra seems to be x86_64*, perhaps it's the same issue? @abenson is there some comment that can be left on the template?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well this should then be at least x86_64* then probably.

revision=1
archs="x86_64"
build_style=cmake
configure_args="-DCMAKE_INSTALL_PREFIX=/usr -DBUILD_CUTTER_PLUGIN=ON -DCUTTER_SOURCE_DIR=${XBPS_BUILDDIR}/cutter-${_cutterversion}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-DCMAKE_INSTALL_PREFIX=/usr is unneeded, specified in the cmake build_style. Also split across two lines, line length should be only 80 characters.

archs="x86_64"
build_style=cmake
configure_args="-DCMAKE_INSTALL_PREFIX=/usr -DBUILD_CUTTER_PLUGIN=ON -DCUTTER_SOURCE_DIR=${XBPS_BUILDDIR}/cutter-${_cutterversion}"
ignore_elf_files="/usr/share/RadareOrg/Cutter/plugins/native/libr2ghidra_cutter.so /usr/share/radare2/plugins/core_ghidra.so"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also split across two lines.

build_style=cmake
configure_args="-DCMAKE_INSTALL_PREFIX=/usr -DBUILD_CUTTER_PLUGIN=ON -DCUTTER_SOURCE_DIR=${XBPS_BUILDDIR}/cutter-${_cutterversion}"
ignore_elf_files="/usr/share/RadareOrg/Cutter/plugins/native/libr2ghidra_cutter.so /usr/share/radare2/plugins/core_ghidra.so"
hostmakedepends="pkg-config cmake git bison flex"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

git is no longer needed AFAICT.

@ghost
Copy link
Author

ghost commented Aug 27, 2020

Thanks, done

@Chocimier
Copy link
Member

Usage of ignore_elf is wrong here, because /usr/share should be still architecture independent.

@ericonr ericonr added the new-package This PR adds a new package label Dec 20, 2020
@github-actions
Copy link

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

@github-actions github-actions bot added the Stale label Apr 18, 2022
@github-actions github-actions bot closed this May 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-package This PR adds a new package Stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants