Ruby 1.8.1 on OpenStep

[Martin Maciaszek]

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. Trying to
build a ruby with --enable-shared has some problems. Some of them I
could fix pretty easily others still leave me stranded.

1. In the Makefile that configure generates LDSHARED is not set which
leads to an error when trying to build a shared libruby. This one is
trivial. It obviously should be set to "libtool -dynamic". The NeXT
documentation states that the object files should be compiled with
-dynamic too. I'm not sure if this is really needed but I added
-dynamic to CFLAGS too.

2. DLDFLAGS contains "$(EXTLDFLAGS) -arch m68k -arch i386 -arch
sparc". libtool(1) doesn't accecpt any -arch parameters. These
obviously don't belong in here

3. LIBRUBY_SO and LIBRUBY_ALIASES assume that shared libraries are
called $SOMETHING.so. This is true on most Unices but not on NS/OS.
Shared libraries have the .dylib file extension on NS/OS.

4. When it comes to linking everything together into libruby I get a
line like this:
libtool -dynamic array.o [...] vsnprintf.o dmyext.o -o
libruby.1.8.1.dylib
This results in a lot of unresolved symbols which can be mostly fixed
by adding /lib/libsys_s.dylib after dmyext.o. I said mostly because it
still leaves me with 1 unresolved symbol: __environ. nm(1) confirms
that __environ is an unresolved symbol in /lib/libsys_s.dylib.

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.

Cheers
Martin

 

[Useko Netsumi]

Talking about OpenStep, where do you get the latest software, if any, and
is it for both x86 and the black-box as well. Thanks

 

[Martin Maciaszek]

Talking about OpenStep, where do you get the latest software, if any, and
is it for both x86 and the black-box as well. Thanks

Which software exactly? The operating system itself can still be
obtained from http://blackholeinc.com (it is probably a lot less
expensive if you have the luck to find it on ebay). A lot of software
can be found on peanuts.org or peak.org. Most software is compiled for
m68k, i386 and sparc. Older software (for NS3.3) additionally contains
code for hppa too.

Cheers
Martin

 

[Martin Maciaszek]

]

4. When it comes to linking everything together into libruby I get a
line like this:
libtool -dynamic array.o [...] vsnprintf.o dmyext.o -o
libruby.1.8.1.dylib
This results in a lot of unresolved symbols which can be mostly fixed
by adding /lib/libsys_s.dylib after dmyext.o. I said mostly because it
still leaves me with 1 unresolved symbol: __environ. nm(1) confirms
that __environ is an unresolved symbol in /lib/libsys_s.dylib.

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.

I still hope that somebody with some knowledge in autoconf/automake
knows how to transform my incoherent babble into some fix

Cheers
Martin

 

[Eric Sunshine]

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.

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

 

[Martin Maciaszek]

On Tue, 13 Jan 2004 23:58:33 +0900, Eric Sunshine

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.

You're right. After I removed the build directory, ruby stopped
working. I'll have to take a closer look at that.

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

I don't know. I just read about it in the ld man-page and thought that
it looked more elegant

Cheers
Martin

 

[Martin Maciaszek]

On Tue, 13 Jan 2004 23:58:33 +0900, Eric Sunshine

You're right. After I removed the build directory, ruby stopped
working. I'll have to take a closer look at that.

A temporary solution to this is to add /usr/local/lib (in my case) to
DYLD_LIBRARY_PATH. It works similar to setting LD_LIBRARY_PATH on
other Unices. I have to take a look if there is a solution that works
without setting env vars. But I'm using NS/OS something over 1 month
now so I still haven't groked all the quirks of that system

Cheers
Martin