# Binary extension compatibility on OS X **URL:** \ **Category:** Ruby\ **Created:** [August 15, 2006, 2:16pm UTC](https://www.ruby-forum.com/t/binary-extension-compatibility-on-os-x/102372 "2006-08-15T14:16:30Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![absolute-beginner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a5b964/32.png) [@absolute-beginner](https://www.ruby-forum.com/u/absolute-beginner)\ **Post date:** [August 15, 2006, 2:16pm UTC](https://www.ruby-forum.com/t/binary-extension-compatibility-on-os-x/102372/1 "2006-08-15T14:16:30Z")
Hi I’m looking at creating some binary gems for OS X. What I’m wondering is, are extensions compiled with one version of the compiler toolchain (7.5.0, 7.9.0, 8.0.0) compatible with Rubies compiled on the same architecture (powerpc or i686) but with a different version number in RUBY\_PLATFORM? Rubygems is puzzlingly inconsistent here: if I build a gem with ‘platform = Gem::Platform::DARWIN’, I get a gem called ‘xxx-powerpc-darwin.gem’ (which suggests ‘yes’ to my question). If I use Gem::Platform::CURRENT, I get one called ‘xxx-powerpc-darwin7.9.0.gem’ (which suggests ‘no’). ps - is there a separate Rubygems platform specification for i686-darwin in the works? Thanks alex ---
**Author:** ![absolute-beginner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a5b964/32.png) [@absolute-beginner](https://www.ruby-forum.com/u/absolute-beginner)\ **Post date:** [August 15, 2006, 7:48pm UTC](https://www.ruby-forum.com/t/binary-extension-compatibility-on-os-x/102372/2 "2006-08-15T19:48:14Z")
On 8/11/06, Alex F. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Hi > > I’m looking at creating some binary gems for OS X. > > What I’m wondering is, are extensions compiled with one version of the compiler toolchain (7.5.0, 7.9.0, 8.0.0) compatible with Rubies compiled on the same architecture (powerpc or i686) but with a different version number in RUBY\_PLATFORM? I guess that on OS X the platform numbers are just parsed from uname or somesuch without trying to interpret thier meaning in any way. So they would probably change while the OS X major version stays the same. I would use sw\_vers to determine OS X version. > Rubygems is puzzlingly inconsistent here: if I build a gem with ‘platform = Gem::Platform::DARWIN’, I get a gem called ‘xxx-powerpc-darwin.gem’ (which suggests ‘yes’ to my question). If I use Gem::Platform::CURRENT, I get one called ‘xxx-powerpc-darwin7.9.0.gem’ (which suggests ‘no’). > > ps - is there a separate Rubygems platform specification for i686-darwin in the works? I’d guess that gems compiled on OS X 10.4 should work on OS X 10.4, they could not work on 10.3, and unless you do something special they would probably fail on earlier versions. The toolchain defaults change generally between the major versions -ie 10.4 uses different default compiler than 10.3, iirc 10.3 used different linker options that 10.2 by default, and some important linker options weren’t even available before 10.2. It’s probably the linker options that changes most, and I am not sure how they affect ruby gem compatibility. I have never tried (at least not intentionally) to load a binary module compiled with different namespace or OS compatibility (deployment target) than that of the interpreter and other modules. I guess the namespace should not matter much as the module is quite separate. But I have no idea what the compatibility setting does (and some other setiings I possibly forgot 🙂 Note that some defaults may be changed when ruby is packaged for a distribution. There are some linker options that should not affect compatibility but affect module behavior. For example, the default for ruby is to compile modules with -undefined suppress (or somesuch) linker flag that ignores undefined symbols. This can produce modules that compile and install happily but fail to load because of the undefined symbols. I patch this to use -undefined error so that no modules with undefined symbols are built. In 10.3 or 10.4 an option -undefined dynamic\_lookup was introduced that makes the dynamic linker attempt to find a library that provides the symbol - at load time. Thanks Michal