On 8/11/06, Alex F. [email protected] 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