-
Notifications
You must be signed in to change notification settings - Fork 17
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
extractcode fails on Fedora 24 #13
Comments
@akaihola Thanks for the report. I will spin a Fedora 24 VM to reproduce the failure. The thing is that the prebuilt native libraries (here |
It looks like it may be a pervasive issue on RedHat-style distros: https://bugzilla.redhat.com/show_bug.cgi?id=461863 and https://www.google.com/search?q="libbz2.so.1.0"+in+Fedora .... |
And more specifically on Fedora: http://forums.fedoraforum.org/showthread.php?t=258694 which seems to stem from the fact that the ScanCode binaries were produced on a debian or ubuntu distro. |
@pombredanne, yes, I'm running the 64-bit variant of Fedora 24. |
Since Scancode binaries are built on Debian based machines, and the prebuilt dependencies are named differently on RedHat based machines py.test will not be able to find the libbz2.so library on those machines. See https://github.com/nexB/scancode-toolkit/issues/443 Added a note about how to work around this issue by symbolically linking the existing libbz2.so on the filesystem to the expected name. This should be removed once aboutcode-org#469 is solved Signed-off-by: Nisha K <nishak@vmware.com>
Since Scancode binaries are built on Debian based machines, and the prebuilt dependencies are named differently on RedHat based machines py.test will not be able to find the libbz2.so library on those machines. See https://github.com/nexB/scancode-toolkit/issues/443 Added a note about how to work around this issue by symbolically linking the existing libbz2.so on the filesystem to the expected name. This should be removed once #469 is solved Signed-off-by: Nisha K <nishak@vmware.com>
Since Scancode binaries are built on Debian based machines, and the prebuilt dependencies are named differently on RedHat based machines py.test will not be able to find the libbz2.so library on those machines. See https://github.com/nexB/scancode-toolkit/issues/443 Added a note about how to work around this issue by symbolically linking the existing libbz2.so on the filesystem to the expected name. This should be removed once aboutcode-org#469 is solved Signed-off-by: Nisha K <nishak@vmware.com>
Would be nicer if instructions on how to replace the prebuilt binaries were added :-) |
@armijnhemel agreed. I am working on something there. |
On Fedora 24, I get this:
It starts working correctly if I run this:
The text was updated successfully, but these errors were encountered: