Bug #20635: Can't build fat binaries on Darwin (Mac OS X)

• Status: Feedback
• Assignee: -
• Target version: -
• ruby -v: It never gets that far!
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[gsteemso (Gordon Steemson)]

[background: I'm attempting to build the latest versioned release of Ruby (3.3.4) on a 2005-vintage dual-processor Power Mac G5 – that's a 64-bit big-endian machine. I'm using the newest Mac OS available for it, which is version 10.5.8 from 2011. I also had exactly the same issues described below with release 3.3.3 of Ruby.]

Ruby still maintains the capability, in theory, to be built for multiple architectures at once on Mac OS X (Darwin) by passing "-arch xxxx" flags to the compiler. Alas, that is currently failing to work on PowerPC when it gets to the coroutines, which configure inexplicably thinks ought to be built bi-endian. As Apple only ever implemented big-endian Power Macs, it dies messily when it tries to build the little-endian part. I've been able to inefficiently bypass the issue, albeit for only one architecture at a time, by manually supplying the correct values of "--with-coroutine=xxxx" and "ac_cv_c_bigendian=xxxx" to configure.

While I'm on the subject, on my system configure happens to discover an OS routine called "fcopyfile", which apparently does not behave here as it is expected to on more modern systems. I must manually pass "ac_cv_func_fcopyfile=no" to configure, or chaos ensues.

Even with these tricks apparently solving all the problems, every build I have tried dies with a series of bus errors when it attempts to link miniruby (the specific names given most often are "[builtin_binary.inc]" and "[.rbconfig.time]"). As far as I've been able to work out, "bus error" means it tried to execute something at a misaligned address. I have no idea how to debug that.

[nobu (Nobuyoshi Nakada)]

Could you show the actual error messages?

[alanwu (Alan Wu)]

• Status changed from Open to Feedback

[gsteemso (Gordon Steemson)]

Apologies for the delay in responding. The two-factor authentication had me locked out of this site.

Regarding the request for verbatim error messages:

Well, there are several thousand initial lines of compiler warnings which permute depending upon the options selected, but which have absolutely no relation to this topic, no matter what options one actually chooses. The bit that only happens when “--arch=ppc,ppc64” is passed to ./configure is as follows:

assembling coroutine/universal/Context.S
./coroutine/ppc64le/Context.S:8:Unknown pseudo-op: .type
./coroutine/ppc64le/Context.S:8:Rest of line ignored. 1st junk character valued 95 (_).
./coroutine/ppc64le/Context.S:8:Invalid mnemonic 'function'
./coroutine/ppc64le/Context.S:11:Parameter syntax error (parameter 1)

(it repeats that last error verbatim for almost every line of the input file, up to:)

./coroutine/ppc64le/Context.S:64:Parameter syntax error (parameter 1)
./coroutine/ppc64le/Context.S:65:Parameter syntax error (parameter 2)
./coroutine/ppc64le/Context.S:68:Parameter syntax error (parameter 1)
lipo: can't open input file: /var/folders/io/ioPBC6PtG3C9BX7clOTg2k+++TI/-Tmp-//ccDVq6xe.out (no such file or directory)
make: *** [coroutine/universal/Context.O] Error 1

This reveals that it's trying to assemble for 64-bit little-endian, but not a lot else. I do note that it makes no mention of any other endianness or data width, so presumably the 32-bit part assembled without it feeling a need to comment, and I suspect that I may have guessed wrong about it attempting to compile for both endiannesses – if it had succeeded with some big-endian 64-bit part, lipo would not have been complaining that its input file was absent.

Is there anything else I can look at or query that may aid in diagnosing this issue?

[alanwu (Alan Wu)]

If you run make V=1, you can get the command which causes the SIGBUS. With that, you can run it under a debugger (not sure whether it was LLDB or GDB in OS X) and get a backtrace. --with-coroutine is probably the way to go for vintage systems.