Opened 4 weeks ago
Last modified 2 weeks ago
#837 new defect
Error compiling Ruby bindings with Ruby from Nixpkg
Reported by: | Graeme Porteous | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Xapian-bindings (Ruby) | Version: | |
Severity: | minor | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Operating System: | All |
Description
The Ruby symbols aren't available when compiling and results in an error:
======================================================================== _wrap_LatLongCoords_size(int, unsigned long*, unsigned long) in xapian_wrap.o _wrap_Database_size(int, unsigned long*, unsigned long) in xapian_wrap.o _wrap_Database_get_total_length(int, unsigned long*, unsigned long) in xapian_wrap.o _wrap_Database_get_revision(int, unsigned long*, unsigned long) in xapian_wrap.o _wrap_Database_check(int, unsigned long*, unsigned long) in xapian_wrap.o "_rb_undef_alloc_func", referenced from: _Init__xapian in xapian_wrap.o "_rb_undef_method", referenced from: _Init__xapian in xapian_wrap.o "_rb_unexpected_type", referenced from: _Init__xapian in xapian_wrap.o ld: symbol(s) not found for architecture arm64 clang++: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [Makefile:741: _xapian.la] Error 1 make[3]: Leaving directory './xapian-full/tmp/aarch64-apple-darwin24.2.0/ports/xapian-bindings/1.4.22/xapian-bindings-1.4.22/ruby' make[2]: *** [Makefile:670: all] Error 2 make[2]: Leaving directory './xapian-full/tmp/aarch64-apple-darwin24.2.0/ports/xapian-bindings/1.4.22/xapian-bindings-1.4.22/ruby' make[1]: *** [Makefile:514: all-recursive] Error 1 make[1]: Leaving directory './xapian-full/tmp/aarch64-apple-darwin24.2.0/ports/xapian-bindings/1.4.22/xapian-bindings-1.4.22' make: *** [Makefile:436: all] Error 2 ========================================================================
This can be solved by setting the LIBS
environment variable to RbConfig::CONFIG["LIBRUBYARG"]
as has been done here for our Ruby gem:
https://github.com/mysociety/xapian-full/pull/11
I was wondering if a more appropriate change would be to update configure.ac to set RUBY_LIBS
automatically if null
, something along the lines of:
https://github.com/mysociety/xapian-full/issues/10#issuecomment-2575244213
Attachments (2)
Change History (5)
comment:1 by , 4 weeks ago
follow-up: 3 comment:2 by , 3 weeks ago
I wonder if you missed my question above...
Can you show the full log mentioned in the output:
Running 'compile' for xapian-bindings 1.4.22... ERROR, review './xapian-full/tmp/aarch64-apple-darwin24.2.0/ports/xapian-bindings/1.4.22/compile.log' to see what happened. Last lines are:
I'm guessing nixpkg is forcing linking with -z defs
(or -Wl,-z,-defs
or some equivalent or similar option) for some reason but it would be good to confirm.
by , 2 weeks ago
Attachment: | compile.log added |
---|
by , 2 weeks ago
Attachment: | configure.log added |
---|
comment:3 by , 2 weeks ago
I have attached logs for configure and compile. I hope this helps understand what is going on here. I must admit I'm out of my depth understanding what is going on here.
Replying to Olly Betts:
I wonder if you missed my question above...
Can you show the full log mentioned in the output:
Running 'compile' for xapian-bindings 1.4.22... ERROR, review './xapian-full/tmp/aarch64-apple-darwin24.2.0/ports/xapian-bindings/1.4.22/compile.log' to see what happened. Last lines are:
I'm guessing nixpkg is forcing linking with
-z defs
(or-Wl,-z,-defs
or some equivalent or similar option) for some reason but it would be good to confirm.
The patch there is overly complicated since
RUBY_LIBS
is set to empty just before, so the amended conditional will always be true and it would be simpler and clearer to just scrap the conditionalisation entirely.In the comment over there it says "Issue is with the compiler non being able to find the Ruby headers" but that's not correct as this is nothing to do with the headers - it's a link time problem to do with the symbols not being found in a library.
I don't understand why this fails though - most platforms allow undefined symbols when linking a shared object (which then get resolved by the dynamic linker when the library is loaded at runtime). The major exception is Microsoft Windows, essentially because DLLs are a really ancient technology and rather lacking in features, so there we pass
-no-undefined
tolibtool
in_xapian_la_LDFLAGS
which means we need to explicitly link to libruby.Can you show the full log mentioned in the output:
We could enable linking to libruby everywhere but I'm not sure of the full implications - it seems like something we'd want to test carefully before changing which is a pain, especially for platforms we lack CI for.