Sup on M1, M2 Mac / Apple Silicon

[hmltn-2]

I am pretty sure the gem installation does not work on Mac M1 / Apple Silicon.

I might try to fork it and see if I can build it from source and if I need to modify anything.

If anyone can please let me know more information about this I'd appreciate it.

Thanks.

[danc86]

What error are you seeing?

Sup and all its dependencies does build and work fine on aarch64 Linux (I use it on aarch64 Linux every day) but of course Mac OS is different in many ways. If you can paste an error I can try to guess what might be going wrong, although I do not use or own a Mac, nor do I know much about the operating system.

[barracuda156]

@danc86 Fails for me on macOS:

_rb_undef_method, referenced from:\n      _Init__xapian in xapian_wrap.o\n  _rb_unexpected_type, referenced from:\n      _Init__xapian in xapian_wrap.o\nclang: error: linker command failed with exit code 1 (use -v to see invocation)\nmake[3]: *** [_xapian.la] Error 1\nmake[2]: *** [all] Error 2\nmake[1]: *** [all-recursive] Error 1\nmake: *** [all] Error 2

rb33-sup_Sonoma.log

[danc86]

This error seems to be in building the SWIG-generated wrapper code for the Ruby Xapian bindings, which comes from the xapian-ruby gem.

That gem itself is just a republished wrapper around the official Xapian Ruby bindings. It's possible that the gem is outdated or doing something wrong, but it's more likely that the Xapian bindings need some fixing to compile successfully on the latest Mac OS.

You could try building the bindings by hand, and see if that gives any more clues. You can use sup with the xapian bindings built this way: https://github.com/sup-heliotrope/sup/wiki/Installation%3A-OpenBSD

If it still fails to build then it's best to file a bug report against Xapian. I tried searching for any similar looking bugs but their issue tracker seems to be down unfortunately :grimacing: https://trac.xapian.org/report

[barracuda156]

@danc86 Thank you, I will try.

P. S. On a side note: looks like I haven’t built xapian-core on PowerPC earlier (there was no need for it until now), and I cannot test it right now (temporarily no access to hardware); do you have an idea if that could work or something there relies on newer SDKs? Port installation history for the past year shows 10.11+, though it does not necessarily mean that no one installed it on earlier systems (statistics won’t be sent to Macports by default, plus older macOS require a custom Macports set-up for it to work due to outdated system curl).

[barracuda156]

@danc86 A quick update, xapian-bindings install fine on their own on Sonoma (turned out Macports has them already, I just added support for Ruby 3.3).

I need to figure out how to configure sup gem to use those, since by default they are not picked.

UPD. At the same time, xapian-ruby gem is broken: https://github.com/Garaio-REM/xapian-ruby/issues/10 Looks like it tries to link against a wrong C++ runtime, at the very least.

UPD2. Perhaps this should be changed? https://github.com/sup-heliotrope/sup/commit/5ef7a241d2110a3b9ec0baef0e013eb24be98e4f I do not see a configure option to choose pre-installed Xapian bindings, and the gem is broken.

[barracuda156]

@danc86 Could you help with adding a configure option to use external Xapian bindings? That is the easiest solution, perhaps, rather than trying to fix broken gems (xapian-full-alaveteli gem also fails to build, so it looks like the bug is with Xapian upstream, but it is fixed in Macports, so we can just use that).

[danc86]

We have this hack, which tries to conditionally install the xapian-ruby gem unless running on OpenBSD: https://github.com/sup-heliotrope/sup/blob/develop/ext/mkrf_conf_xapian.rb#L17

I'm not sure if there is a nicer way to have "optional" gem dependencies...

[barracuda156]

We have this hack, which tries to conditionally install the xapian-ruby gem unless running on OpenBSD: https://github.com/sup-heliotrope/sup/blob/develop/ext/mkrf_conf_xapian.rb#L17

I'm not sure if there is a nicer way to have "optional" gem dependencies...

@danc86 Yes, I have seen that and referred to above. So I guess, we want to skip building xapian-ruby for Darwin as well, not only for OpenBSD. (Though there should be a way to do it conditionally on a user choice instead of hardcoding on the system, which is prone to failure.)

[barracuda156]

@danc86 Since I am not sure how to patch a gem before building, I switched the port to use the source from here, which I patched to remove Xapian compilation (in effect, make OpenBSD case the default and only one). That appears to work, I get sup installed. However, running it fails:

% /opt/local/bin/sup-3.3
/opt/local/lib/ruby3.3/gems/3.3.0/gems/lockfile-2.1.3/lib/lockfile.rb:308: warning: finalizer references object to be finalized
[2024-02-27 22:07:08 +0700] ERROR: oh crap, an exception
----------------------------------------------------------------
We are very sorry. It seems that an error occurred in Sup. Please
accept our sincere apologies. Please submit the contents of
/Users/svacchanda/.sup/exception-log.txt and a brief report of the
circumstances to https://github.com/sup-heliotrope/sup/issues so that
we might address this problem. Thank you!

Sincerely,
The Sup Developers
----------------------------------------------------------------
--- ArgumentError from thread: main
mbox URI ('mbox:///Users/svacchanda/.sup/sent.mbox') cannot have a host: 
/opt/local/lib/ruby3.3/gems/3.3.0/gems/sup-1.1/lib/sup/mbox.rb:33:in `initialize'
/opt/local/lib/ruby3.3/gems/3.3.0/gems/sup-1.1/lib/sup/sent.rb:44:in `initialize'
/opt/local/lib/ruby3.3/gems/3.3.0/gems/sup-1.1/lib/sup/sent.rb:22:in `new'
/opt/local/lib/ruby3.3/gems/3.3.0/gems/sup-1.1/lib/sup/sent.rb:22:in `default_source'
/opt/local/lib/ruby3.3/gems/3.3.0/gems/sup-1.1/lib/sup/util.rb:585:in `method_missing'
/opt/local/lib/ruby3.3/gems/3.3.0/gems/sup-1.1/bin/sup:168:in `<module:Redwood>'
/opt/local/lib/ruby3.3/gems/3.3.0/gems/sup-1.1/bin/sup:76:in `<top (required)>'
/opt/local/bin/sup-3.3:25:in `load'
/opt/local/bin/sup-3.3:25:in `<main>'

At the same time, running sup-config works, at least I get meaningful questions:

% /opt/local/bin/sup-config-3.3
Howdy neighbor! This here's sup-config, ready to help you jack in to
the next generation of digital cyberspace: the text-based email
program. Get ready to be the envy of everyone in your internets
with your amazing keyboarding skills! Jump from email to email with
nary a click of the mouse!

Just answer these simple questions and you'll be on your way.
. . .
What file contains your signature? (enter for "/Users/svacchanda/.signature"): 
What editor would you like to use? (enter for "/usr/bin/vim -f -c 'setlocal
spell spelllang=en_us' -c 'set filetype=mail'"): 
Would like to display time in 12h (type 12h) or in 24h (type 24h)?: 24h

Now, we'll tell Sup where to find all your email.
Current sources:
  No sources!

1. Add a new source.
2. Done adding sources!

I guess I did something wrong, but I am not sure what to fix :)

[danc86]

It's getting a bit off-topic for this issue now, but that look like an issue with Ruby 3.2 which I fixed in this commit: https://github.com/sup-heliotrope/sup/commit/d2a2a0d7544237a29bf932773cc85e9050bd9c26 (not released yet). If you're running from source, please try the develop branch, it has a few fixes for recent Rubies. We are probably overdue for a new release.

[barracuda156]

@danc86 Thank you, will try it.

If we could think of some reasonable way to optionally use pre-built Xapian bindings on macOS (or perhaps any system) instead of force-building those (which is broken), without patching the sources from our side, it would be very helpful. I think it will also be a general improvement, not just a fix specifically for MacPorts users. At least for all systems using package managers (FreeBSD, NetBSD etc.).

[barracuda156]

@danc86 Yes, develop branch works!

(Please consider some solution to allow external Xapian bindings before releasing the new version.)

[danc86]

I did a bit of searching to understand if there is any better solution these days for optional gem dependencies, or conditional dependencies, or platform-specific dependencies... and it seems like there is none, apart from the extconf.rb hack which sup already uses.

In commit 492091ad4d544da7fce650b70347a151f5edb053 I changed the condition to check for a SUP_SKIP_XAPIAN_GEM_INSTALL environment variable, instead of conditionalising on OpenBSD.

[barracuda156]

@danc86 Thank you!

[danc86]

Sup 1.2 is released.