From: Blair Zajac <blair@...>
Date: 2005-11-02T14:40:45+09:00
Subject: Re: [ ruby-Bugs-2715 ] [PATCH] 1.8.3 ruby.c doesn't compile on OS X due to missing char **environ

Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: [ ruby-Bugs-2715 ] [PATCH] 1.8.3 ruby.c doesn't compile on OS X due to missing char **environ"
>     on Tue, 25 Oct 2005 15:09:54 +0900, noreply@rubyforge.org writes:
> 
> |I'm working on getting Ruby 1.8.3 into Fink, the Debian style
> |package managed system for Mac OS X.
> |
> |Ruby 1.8.3 introduced the usage of the
> |
> |extern char **environ;
> |
> |in ruby.c.
> |
> |Mac OS X does not have this symbol, which you can confirm by greping
> |through /usr/include and nm on the /usr/lib/*.
> |
> |The work around is to do something like this:
> 
> I'm not sure if it's OK to replace environ by _NSGetEnviron() since
> this code assumes UNIX style environment variable memory map.  Could
> anyone confirm this is OK or not for Mac OS X?
> 
> 							matz.

Hello,

This is a follow up note to all the replies to my original bug report.

Let me provide a little more background information.  I'm one of the Fink
maintainers that's supporting the Ruby package and upgrading it from 1.8.1 to 1.8.3.

One of the differences between the vanilla build and the Fink build is that the
vanilla build uses this link:

$ cc -dynamiclib -undefined suppress -flat_namespace -install_name
/tmp/blair/rrr-1/lib/libruby.dylib -current_version 1.8.3 -compatibility_version
1.8 ........ -o libruby.1.8.3.dylib

while Fink does not suppress undefined symbols and uses this:

$ cc -dynamiclib -install_name /sw/lib/libruby.1.8.dylib -current_version 1.8.3
-compatibility_version 1.8 ........ -o libruby.1.8.3.dylib

With the Fink link, I get

ld: Undefined symbols:
_environ
/usr/bin/libtool: internal link edit command failed
make: *** [libruby.1.8.3.dylib] Error 1

Hence my original patch to change the environ.

Regarding _NSGetEnviron and the memory map, I don't know, but you're already
using this in several places in ruby:

eval.c:

#if defined(__APPLE__)
#define environ (*_NSGetEnviron())
#elif !defined(_WIN32) && !defined(__MACOS__) || defined(_WIN32_WCE)
extern char **environ;
#endif
char **rb_origenviron;


hash.c:

#ifdef _WIN32
#define GET_ENVIRON(e) (e = rb_w32_get_environ())
#define FREE_ENVIRON(e) rb_w32_free_environ(e)
static char **my_environ;
#undef environ
#define environ my_environ
#elif defined(__APPLE__)
#undef environ
#define environ (*_NSGetEnviron())
#define GET_ENVIRON(e) (e)
#define FREE_ENVIRON(e)
#else
extern char **environ;
#define GET_ENVIRON(e) (e)
#define FREE_ENVIRON(e)
#endif

If I may suggest, maybe this common code for environ could be moved into a .h file.

Another point, the Fink package patches the builds to remove the '-undefined
suppress' from all links, including building the extension bundles.  Would it be
a good idea to remove this linker option, to catch bugs like this?

<speculation>
I'm not exactly clear why this works in the vanilla build even when ruby.c
declares char **environ as extern, but the symbol does appear to be created, as
it exists in the resulting ruby binary that is dynamically linked against
libruby.dylib:

$ nm /tmp/blair/rrr-1/bin/ruby |grep environ
00002008 D _environ

$ otool -L /tmp/blair/rrr-1/bin/ruby
/tmp/blair/rrr-1/bin/ruby:
         /tmp/blair/rrr-1/lib/libruby.dylib (compatibility version 1.8.0,
current version 1.8.3)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 71.1.4)
         /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version
227.0.0)
</speculation>

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/