Ruby on HP-UX

I’ll work on at least openssl, since it is the squeaky wheel at the
moment.
I’m having issues with it’s makefile at the moment. Incidentally, why
are
you refering to libcrypto, when the error is related to crypto? Is
crypto
somehow contained in the libcrypto file? I ask because I have a ’
libcrypto.sl’ file on my system, but no ‘crypto.sl’, so I sense the
difference may be important to me in some way. I’ll paste the error
below,
so you don’t have to refer back to my original message to the forum…

gmake[1]: Entering directory
/home/tnordloh/ruby/ruby-1.8.4/ext/digest/md5' ld -b -E -L"../../.." -o ../../../.ext/hppa2.0w-hpux11.11/digest/md5.sl md5init.o md5ossl.o -lcrypto -ldld -lcrypt -lm -lc *ld: Can't find library: "crypto"* gmake[1]: *** [../../../.ext/hppa2.0w-hpux11.11/digest/md5.sl] Error 1 gmake[1]: Leaving directory /home/tnordloh/ruby/ruby-1.8.4/ext/digest/md5’
gmake: *** [all] Error 1

I did read your original message, and I apologize for not understanding
it.
It’s too high-level for me. For example, when you talk about “disable
ipv6
and wide-getaddrinfo so it uses Ruby’s built-in getaddrinfo() instead” I
ask
the question “how?” I don’t believe I have IPv6 enabled, so maybe I’m
good
on this step.

On 3/22/06, MenTaLguY [email protected] wrote:

If I remember correctly, the list of essential libraries is something
now. It’ll be pretty obvious if you’re still missing one, though.

Make sure that these are all available as either shared libraries

 how do I make sure of this?

or
(failing that) that they were at least built as position-independent
code. Otherwise the HP-UX dynamic linker will choke at runtime because
it can’t relocate the static objects HP’s linker blindly imports into
shared libraries.

See my old post that I linked to for more details and other tweaks that
need to be made to specific libraries for HP-UX.

-mental

Thanks, Mental, that helped immensely. I’m learning a lot.

Ok, openssl was a pain to compile but luckily the instructions at the HP
Software and Porting archive told me what I needed to know, namely to go
into one of the makefiles and replace the shared library extension
“.so” with “.sl”. Once I did that, I got much closer: only ‘openssl’
and
‘zlib’ remain uncommented in ext/Setup. Not too shabby. Of course,
it’s
all for naught at this point, for I continue to receive the same error
from
yaml.rb when I try and run ‘ri’.

root@atcito01 [/home/tnordloh/ruby/ruby-1.8.4]

ri File

/usr/local/lib/ruby/1.8/yaml.rb:87: uninitialized constant
YAML::Syck::Resolver (NameError)
from /usr/local/lib/ruby/1.8/rdoc/ri/ri_descriptions.rb:1
from /usr/local/lib/ruby/1.8/rdoc/ri/ri_reader.rb:1
from /usr/local/lib/ruby/1.8/rdoc/ri/ri_driver.rb:5
from /usr/local/bin/ri:43

I’m going to grab some lunch, get some real work done, and pick it up
this
evening.

export CPPFLAGS="-I/usr/local/include"
export LDFLAGS="-L/usr/local/lib -Wl,+b -Wl,/usr/local/lib"

The above didn’t make a difference for me, but since I had compiled
openssl
at this point, simply adding -L"/usr/local/ssl/lib" to the LIBPATH in
relevant Makefiles seemed to do the trick. I’ll go ahead and follow the
very first suggestion I got on this, and supply that path when I run the
./configure script…

.> For example, when you talk about "disable ipv6 and wide-getaddrinfo
so it
uses Ruby’s

built-in getaddrinfo() instead" I ask the question “how?” I don’t believe
I have IPv6
enabled, so maybe I’m good on this step.

Those refer to commandline options to pass when running Ruby’s configure
script:

–disable-ipv6 --disable-wide-getaddrinfo

got it, thanks.

On Thu, 23 Mar 2006 13:36:34 +0900, “Tim Nordloh” [email protected]
wrote:

I’ll work on at least openssl, since it is the squeaky wheel at the moment.
I’m having issues with it’s makefile at the moment. Incidentally, why are
you refering to libcrypto, when the error is related to crypto? Is crypto
somehow contained in the libcrypto file?

Yes. The way libraries work on unix, if you specify -lcrypto, the
linker looks for a libcrypto.sl or a libcrypto.a.

Incidentally, since you may not be aware – in general HP-UX’s tools
don’t know to look in /usr/local by default. If you’ve got required
libraries, you’ll need to have the following environment variables set
at build-time:

export CPPFLAGS=“-I/usr/local/include”
export LDFLAGS=“-L/usr/local/lib -Wl,+b -Wl,/usr/local/lib”

This holds for building software on HP-UX in general. The
-I/usr/local/include is so that it can find the header files at compile
time, the -L/usr/local/lib is so it can find the library files at link
time, and the -Wl,+b -Wl,/usr/local/lib is so that the linked program
can find the libraries again at runtime. This last one is sort of a
peculiarity of HP-UX.

Unfortuantely openssl’s build system is weird, so I can’t promise that
it respects those environment variables. It’s been a while since I’ve
done it myself. You might have to do some makefile hacking after
running ./Configure.

For example, when you talk about “disable ipv6 and wide-getaddrinfo so it uses Ruby’s
built-in getaddrinfo() instead” I ask the question “how?” I don’t believe I have IPv6
enabled, so maybe I’m good on this step.

Those refer to commandline options to pass when running Ruby’s configure
script:

–disable-ipv6 --disable-wide-getaddrinfo

Those should get passed down to ext/socket/extconf.rb; if it turns out
that name resolution still doesn’t work from Ruby, you may have to rerun
ext/socket/extconf.rb explicitly with those options, run make, and
replace the broken installed socket.sl manually.

[ For what it’s worth, on most platforms Ruby’s build system can detect
the absence of a working getaddrinfo() automatically, but HP-UX’s
getaddrinfo() implements just enough to fool the tests into thinking
it’s usable. ]

 how do I make sure of this?  [that shared libraries get built]

This will vary from library to library; the desired end result is that
you have an .sl version of the library installed.

For libraries with a standard autoconf-based build system, that usually
means passing --enable-shared as an argument to ./configure. To achieve
this for openssl, however, this means configuring the library with
something like:

./Configure hpux-parisc shared

(hopefully I’m remembering the platform string correctly)

-mental

New steps:

  1. install openssl(instructions on HP Software porting archive)
  2. untar+gunzip ruby
  3. run configure with these options
    –with-openssl-dir=/usr/local/ssl/
    –disable-ipv6
    –disable-wide-getaddrinfo
  4. Edit DLDFLAGS in Makefile, remove the extra -E flag there.
  5. run “gmake all” in base ruby directory
  6. run “gmake install-all”

By redoing the ./configure and including the --with-openssl-dir command,
I
got openssl to compile, leaving iconv and zlib as the final victims. I
wonder which one YAML is relying on, causing my error. I’m going to
guess
iconv and concentrate my efforts there, but if I’m wrong, someone chime
in
and let me know :slight_smile:

Ok, I’ve had to install 2 libraries so far, do get all of the dynamic
linking to take. my new list of steps below reflect that change.

  1. install openssl(instructions on HP Software porting archive)
  2. install libiconv(configure, make and make all ran ok for me)
  3. untar+gunzip ruby
  4. run configure with these options
    –with-openssl-dir=/usr/local/ssl/
    –with-iconv-dir=/usr/local
    –disable-ipv6
    –disable-wide-getaddrinfo
  5. Edit DLDFLAGS in Makefile, remove the extra -E flag there.
  6. run “gmake all” in base ruby directory
  7. run “gmake install-all”

None of this has actually done any good toward the source error:

$ ri File
/usr/local/lib/ruby/1.8/yaml.rb:87: uninitialized constant
YAML::Syck::Resolver (NameError)
from /usr/local/lib/ruby/1.8/rdoc/ri/ri_descriptions.rb:1
from /usr/local/lib/ruby/1.8/rdoc/ri/ri_reader.rb:1
from /usr/local/lib/ruby/1.8/rdoc/ri/ri_driver.rb:5
from /usr/local/bin/ri:43

ok, I have one library left to compile by hand, the zlib. That
will
complete all basic libraries, and I’d bet at least one penny that it
won’t
help. So I guess I need to start asking about other reasons why this
constant isn’t initialized. Anyone have any clue?

On Fri, 31 Mar 2006 03:41:24 +0900, “Tim Nordloh” [email protected]
wrote:

None of this has actually done any good toward the source error:

$ ri File
/usr/local/lib/ruby/1.8/yaml.rb:87: uninitialized constant
YAML::Syck::Resolver (NameError)
from /usr/local/lib/ruby/1.8/rdoc/ri/ri_descriptions.rb:1
from /usr/local/lib/ruby/1.8/rdoc/ri/ri_reader.rb:1
from /usr/local/lib/ruby/1.8/rdoc/ri/ri_driver.rb:5
from /usr/local/bin/ri:43

I’m puzzled by this one – for whatever reason, syck isn’t getting
loaded. I’ve not had this problem on HP-UX myself, and yaml.rb has a
require ‘yaml/syck’ at the top, so I don’t know why you’re not getting
an error from rather than getting this far.

If you try:

ruby -r ‘yaml/syck’ -e ‘p YAML::Syck::Resolver’

…what happens?

Also, this is 1.8.4, right?

-mental

Tim Nordloh schrieb:

Nothing better than looking like a moron to the entire Ruby community at
once, it saves time.

Rofl, don’t worry too much. Most of us don’t use HP-UX (like me) and
don’t read this thread at all … well … most of the time.

If this does ease your pain: It will certainly make me feel a bit less
lost and lonely when hunting down linker errors or solving dynamic
binding riddles the next time.

So thanks for charing your experiments and insights.

cheers

Simon

On Fri, 31 Mar 2006 04:41:54 +0900, “Tim Nordloh” [email protected]
wrote:

So my last set of steps works, but some of them are unnecessary. I do
have one little issue where I’m still manually editing the Makefile to remove
the extra -E…

I have the extra -E, but it doesn’t cause problems. What version of gcc
are you using, and are you using GNU ld or HP’s ld? (I’m using the
latter, as grotty as it is…)

-mental

I’m puzzled by this one – for whatever reason, syck isn’t getting
loaded.
I’ve not had this problem on HP-UX myself, and yaml.rb has a require
‘yaml/syck’ at the top, so I don’t know why you’re not getting an error
from
rather than getting this far.

Good point, and your saying it made me go check myself. Man, I hate it
when
it turns out that the problem is my fault. I did have a problem like
that
early on in the process, so I ended up copying the syck file one
directory
higher. I went and deleted everything in the ruby installed library
directory, and suddenly it ‘ri’ started working.

Nothing better than looking like a moron to the entire Ruby community at
once, it saves time.

So my last set of steps works, but some of them are unnecessary. I do
have
one little issue where I’m still manually editing the Makefile to remove
the
extra -E. Mental, do you have to do that too, or is there something I
should be tweaking in the ./configure command to make that not happen
anymore?

looks like gcc version 3.4.3, and HP’s ld, version B.11.41

On Fri, 31 Mar 2006 07:41:39 +0900, “Tim Nordloh” [email protected]
wrote:

looks like gcc version 3.4.3, and HP’s ld, version B.11.41

Ok … I’ve got gcc version 3.3.2, and HP’s ld, version B.11.18.

I suspect it’s the gcc version, though, since IIRC it’s gcc that’s
complaining about -E?

-mental

Yup, that’s right. I might try upgrading to a more recent version, but
that
isn’t a major tweak to make.

I have a few dozen HP-UX boxes, and I don’t have gcc installed on all of
them, so I suppose if I were really serious about this, I’d have to try
to
build a depot that I can install across the environment, then send it to
the
porting archive once it is perfected :). I don’t even know enough about
building a depot to know how much work that would be but I suppose it
would
involve capturing a list of all files ruby installed, as well as all of
the
linking done by Ruby. I’ll check the lab at work and see if there is a
book
on how to do something like that, but at this point, if someone wants to
install it, I guess their best bet is to work their way through the
thread…

Incidentally, I’ve bumped up against another issue on HP-UX (really,
it’s going to be an issue on any Unix that doesn’t ship with a
/usr/bin/install or equivalent):

Since there’s no ‘install’ available, Ruby falls back to using
./install-sh -c. This is fine when building Ruby, but it means that
rbconfig.rb will set CONFIG[“INSTALL”] = “./install-sh -c” when gems and
ruby extensions are being built. Not all gems have an ./install-sh to
run…

Workaround:

Put a copy of an install-sh at /usr/local/bin/install or similar.

Ideally, do this before building Ruby. If you’ve already built Ruby,
modify rbconfig.rb to point to it – provided you put the install script
somewhere on your path, CONFIG[“INSTALL”] = “install -c” should be fine.

-mental

On Apr 1, 2006, at 10:37 PM, Tim Nordloh wrote:

Yup, that’s right. I might try upgrading to a more recent version,
but that
isn’t a major tweak to make.

1.8.4 is the current version of Ruby.

James Edward G. II