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)

compile.log (21.2 KB ) - added by Graeme Porteous 2 weeks ago.
configure.log (7.2 KB ) - added by Graeme Porteous 2 weeks ago.

Download all attachments as: .zip

Change History (5)

comment:1 by Olly Betts, 4 weeks ago

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

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 to libtool in _xapian_la_LDFLAGS which means we need to explicitly link to libruby.

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:

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.

comment:2 by Olly Betts, 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 Graeme Porteous, 2 weeks ago

Attachment: compile.log added

by Graeme Porteous, 2 weeks ago

Attachment: configure.log added

in reply to:  2 comment:3 by Graeme Porteous, 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.

Note: See TracTickets for help on using tickets.