On Sat, 10 Jan 2004 12:46:37 +0900, Martin Maciaszek wrote:
> First I must say I was very surprised that Ruby has some configure
> options that aid building fat binaries on NS/OS. And it really
> works... at least for completely statically linked builds.

I did a bunch of work recently to revive and improve the NextStep, OpenStep,  
and Rhapsody ports of Ruby.  You can see the details of this effort in the  
"revived NextStep, OpenStep, and Rhapsody ports" ChangeLog entry.

> Maybe somebody with more experience with NS/OS than me (which I use
> for about 1 month now) can point me to a solution. As for the other
> problems I hope that somebody with some knowledge with GNU
> autoconf/automake will find my descriptions useful to fix the
> described problems.

I will try to take a look at this when I find a chance to do so.  However,  
note that, historically, shared libraries were not a developer-level feature  
on NS/OS.  Shared libraries were created by NeXT itself, but there was never  
any published technique for building them.  Back in the NS/OS days, what some  
people called "shared libraries" were actually what we might call "plugin  
modules" today.  These were quite distinct from true shared libraries.

On Mon, 12 Jan 2004 03:31:37 +0900, Martin Maciaszek wrote:
> The last piece of the puzzle is to use -U __environ on this line. This
> will stop libtool from complaining. Another (probably cosmetic) change
> would to use -framework System instead of libsys_s.dylib directly.

Have you actually installed the Ruby built this way and then removed the  
directory in which you built the package?  If so, are you able to load any of  
the extension modules, such as 'digest'?  The reason I ask is that,  
historically, NS/OS hard-coded the pathnames of shared libraries into  
programs/plugins which link against those libraries.  For instance, if you  
built the 'digest' extension by linking it against the shared library  
$HOME/ruby/libruby.dylib, and then you installed Ruby and removed the entire  
$HOME/ruby directory, the 'digest' module would still look for libruby.dylib  
at $HOME/ruby.

What exactly prompted you to use -framework System instead of libsys_s?

-- ES