Fix: Failing references to libc.so on FreeBSD 10 #1659
Comments
iamasmith
changed the title
|
Example failure.. require 'drb'
class MyTest
def hello
puts 'hello'
end
end
DRb.start_service 'drbunix://tmp/test',MyTest.new
DRb.thread.joinandrews@fb10public:~/build/jruby-1.7.12 % jruby ~/test.rb
NativeLibrary.java:87:in `loadNativeLibraries': java.lang.UnsatisfiedLinkError: /usr/lib/libc.so: invalid file format
from NativeLibrary.java:70:in `getNativeLibraries'
from NativeLibrary.java:49:in `getSymbolAddress'
from NativeLibrary.java:59:in `findSymbolAddress'
from AsmLibraryLoader.java:117:in `generateInterfaceImpl' |
|
I got to spend a little time on this today and updated a fix that was added in January to jnr-ffi to deal with Linker scripts. It required some small tweaks to work for JRuby... This obviates the requirements to do anything else it seems if all native calls reaching libc.so go through jnr-ffi. It certainly fixes the Unix Domain Socket issue above. I tested this with today's master branch of jnr-ffi and this seems to have some additional dependency upon ASM, for which I embedded 5.0.2 in the jruby.jar file in testing. |
|
Additional testing performed using Syslog class as one known to use FFI. This worked with just the jar fixes in place (on 1.7.12 that includes the FreeBSD syslog FFI constants). |
iamasmith
changed the title
|
@iamasmith can you check with 1.7.16.1? I'm using -CURRENT with JRuby just fine with a number of native libraries (including some FFI-to-libc stuff) |
|
We've had a number of jnr-ffi updates since this ticket was filed, and I saw this work on 1.7.16.1 last year. I'm going to close it out. If the issue isn't properly fixed, please re-open @iamasmith |
|
Confirmed this is fixed by building from source 1.7.21. Our port on FreeBSD needs some updating I think as it's back at 1.7.15 :p |
|
Submitted a patch to the current port (1.7.15) here, hopefully it will be merged soon. |
In FreeBSD 10 the first occurrence of libc.so on the path happens to be a linker script that unfortunately isn't handled by even the ports provided by the JDK.
This results in various errors when trying to use FFI functions or anything Unix Domain Socket based.
On the face of it this could be interpreted as a port issue requiring a patch to the JDK to handle the linker script, however, correctly specifying a real library IS handled correctly by the JDK so it brings an area of uncertainty as to where the fix should go.
The effected areas seem to be jffi and jnr.unixsocket with independent selection of libc.so by name. In a project like jruby one understands that it is necessary to overlook DRY principle sometimes in favour of taking a straight copy of the component to include in the project.
jffi has some platform specific selections for libc which default out for FREEBSD as libc.so, I don't see any way of observing the OS revision and the os.name simply says 'freebsd' so it doesn't seem pragmatic to approach the jffi folks with a way to go for libc.so.7 instead of libc.so on a FreeBSD 10 platform when earlier revisions will still have os.name = freebsd but their libc.so will be a binary.
jnr.unixsocket has independent code to load libc.so which falls straight into a simple loadLibrary call and similarly fails.
Fix submitted to jnr-ffi mentioned below.
The text was updated successfully, but these errors were encountered: