Forum: Ruby Ruby on HP-UX

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tim Nordloh (Guest)
on 2006-03-21 22:48
(Received via mailing list)
I have read a couple of posts regarding compiling Ruby on HP-UX 11i, and
I'm hoping for a little more insight on the exact requirements of doing
that
type of install.  Basically, the posts I have read haven't been
understandable by someone like me.  an earlier post referred to "disable
ipv6 and wide-getaddrinfo so it uses Ruby's built-in getaddrinfo()
instead."  I have no idea how to do that, I'd love an example command or
something.  I am hoping that I can create a step-by-step procedure for
installation on any HP-UX server, for people like me, where the
high-level
instructions are not helpful.  Without further ado, here is where I've
managed to get so far.

1.  Download the 1.8.4 tar.gz file
2.  run ./configure
3.  run gmake (not make)
4.  run gmake all
at this point, I got the following error:
 ===================================
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
===================================
so, I decided to play with the ext/Setup file mentioned in the README.
By
uncommenting 'option nodynamic' I'm able to get a clean gmake, and then
'gmake all', and I have a supposedly working ruby install (at least irb
functions, and a very basic script works).  The 'ri' command didn't work
though, so on to that....

so now, I want documentation, which seems to be available by running
gmake
install-all
this fails after running for quite some time with the following error:
===================================
 zlib.c:
mcccccccccccccccccc...................................................................................
Generating RI...
/home/tnordloh/ruby/ruby-1.8.4/lib/yaml.rb:87: uninitialized constant
YAML::Syck::Resolver (NameError)
        from
/home/tnordloh/ruby/ruby-1.8.4/lib/rdoc/ri/ri_descriptions.rb:1
        from /home/tnordloh/ruby/ruby-1.8.4/lib/rdoc/ri/ri_reader.rb:1
        from
/home/tnordloh/ruby/ruby-1.8.4/lib/rdoc/generators/ri_generator.rb:46

        from /home/tnordloh/ruby/ruby-1.8.4/lib/rdoc/rdoc.rb:250:in
`document'
        from ./bin/rdoc:63
gmake: *** [do-install-doc] Error 1

My Ruby-expert friend believes this is because I'm missing some C
headers.
Any Ruby install gurus have an idea of what I should try here, or what
I'm
missing?
James G. (Guest)
on 2006-03-21 23:33
(Received via mailing list)
On Mar 21, 2006, at 2:48 PM, Tim Nordloh wrote:

> 4.  run gmake all

Did you mean gmake install-all here?

> My Ruby-expert friend

<laughs>  I know that refers to me, but boy are you confused.  ;)
What I know about the Ruby compile process is limited to: "Works
great on Moc OS X!"  :D

> believes this is because I'm missing some C headers.

Actually, I believe Ruby failed to install its C extensions.  In a
private message, Tim shared the contents of his extension directory:

# ls /usr/local/lib/ruby/1.8/hppa2.0w-hpux11.11/
bigdecimal.sl  defines.h      intern.h       regex.h        util.h
config.h       digest         missing.h      ruby.h         version.h
crypto.h       digest.sl      node.h         rubyio.h
curses.sl      dln.h          rbconfig.rb    rubysig.h
dbm.sl         env.h          re.h           st.h

Compare that with my healthy install:

$ ls /usr/local/lib/ruby/1.8/powerpc-darwin8.3.0/
bigdecimal.bundle       iconv.bundle            rubysig.h
config.h                intern.h                sdbm.bundle
curses.bundle           io                      socket.bundle
dbm.bundle              missing.h               st.h
defines.h               nkf.bundle              stringio.bundle
digest                  node.h                  strscan.bundle
digest.bundle           openssl.bundle          syck.bundle
dl.bundle               pty.bundle              syslog.bundle
dl.h                    racc                    tcltklib.bundle
dlconfig.h              rbconfig.rb             tkutil.bundle
dln.h                   re.h                    util.h
enumerator.bundle       readline.bundle         version.h
env.h                   regex.h                 zlib.bundle
etc.bundle              ruby.h
fcntl.bundle            rubyio.h

I had him try a few tests.  Pure Ruby standard libraries seem to be
just fine, but, as you can see, the C extensions are missing.

James Edward G. II
Stephen W. (Guest)
on 2006-03-21 23:41
(Received via mailing list)
James Edward G. II wrote:
>  but, as you can see, the C extensions are missing.

Yah.. isn't that the rub.  In general, the extension build system leaves
a bit to be desired.

Though, if it can find all it needs to build an extension, it should
build it.  A few things to try..

* Try editing ext/Setup
* Try adding --with-readline-dir=... --with-openssl-dir=..., to your
./configure

HTH,
Steve
Mauricio F. (Guest)
on 2006-03-21 23:51
(Received via mailing list)
On Wed, Mar 22, 2006 at 06:33:50AM +0900, James Edward G. II wrote:
> On Mar 21, 2006, at 2:48 PM, Tim Nordloh wrote:
> I had him try a few tests.  Pure Ruby standard libraries seem to be
> just fine, but, as you can see, the C extensions are missing.

That's what he asked for, by disabling shared libs:

>>so, I decided to play with the ext/Setup file mentioned in the README. By
>>uncommenting 'option nodynamic' I'm able to get a clean gmake, and then
  ==============================
>>'gmake all', and I have a supposedly working ruby install (at least irb
>>functions, and a very basic script works).

He could either uncomment the desired extensions in ext/Setup so they're
linked
statically, or skip digest/* (and probably other extensions) to get a
clean
build, without disabling dynamic modules altogether.
Tim Nordloh (Guest)
on 2006-03-21 23:51
(Received via mailing list)
in what way should I edit /ext/setup?  Is there a readme on my options?

Also, I'm assuming the --with-openssl-dir parameter needs to be the
'include' directory?  Here's what I tried, and the result.

$ ./configure --with-openssl-dir=/usr/local/include/openssl
./configure[88]: conf576.sh: Cannot create the specified file.
./configure[89]: conf576.sh: Cannot create the specified file.
chmod: can't access conf576.sh
./configure[201]: conf576.file: Cannot create the specified file.
./configure[996]: config.log: Cannot create the specified file.
James G. (Guest)
on 2006-03-21 23:55
(Received via mailing list)
On Mar 21, 2006, at 3:51 PM, Mauricio F. wrote:

>>> and then
>   ==============================
>>> 'gmake all', and I have a supposedly working ruby install (at
>>> least irb
>>> functions, and a very basic script works).
>
> He could either uncomment the desired extensions in ext/Setup so
> they're linked
> statically, or skip digest/* (and probably other extensions) to get
> a clean
> build, without disabling dynamic modules altogether.

Any idea why digest threw a fit?

James Edward G. II
Tim Nordloh (Guest)
on 2006-03-22 00:07
(Received via mailing list)
Looking into it, I might be able to download a newer version, if it's
something I have control over.  I'll let you know ASAP
Tim Nordloh (Guest)
on 2006-03-22 00:48
(Received via mailing list)
ok, I uncommented entries in the ext/Setup file one-by-one, and here's
what
I ended up with:

root@atcito01 [/home/tnordloh/ruby/ruby-1.8.4]
# cat ext/Setup
#option nodynamic

#Win32API
bigdecimal
curses
dbm
#digest
digest/md5
digest/rmd160
digest/sha1
digest/sha2
#dl
#enumerator
#etc
#fcntl
#gdbm
iconv
#io/wait
#nkf
#pty
openssl
#racc/cparse
#readline
#sdbm
#socket
#stringio
#strscan
#syck
#syslog
#tcltklib
#tk
#win32ole
zlib

I'm back to 'gmake' at this point and it fails at the ruby compile like
so...

making ruby
gmake[1]: Entering directory `/home/tnordloh/ruby/ruby-1.8.4'
gcc -g -O2  -DRUBY_EXPORT -DYYMAXDEPTH=300   -I. -I.  -oext/extinit.o -c
ext/extinit.c
gcc -g -O2  -DRUBY_EXPORT -DYYMAXDEPTH=300   -Wl,-E -L.
-L"/usr/local/include/openssl/lib" -E  main.o ext/extinit.o
ext/bigdecimal/bigdecimal.a ext/curses/curses.a ext/dbm/dbm.a
ext/digest/md5/md5.a ext/digest/rmd160/rmd160.a ext/digest/sha1/sha1.a
ext/digest/sha2/sha2.a ext/iconv/iconv.a ext/openssl/openssl.a
ext/zlib/zlib.a -lruby-static -ldld -lcrypt -lm  -lcur_colr -ltermcap
-lssl
-lcrypto -liconv -lnsl -lz -o ruby
gcc: -E: linker input file unused because linking not done
gcc: main.o: linker input file unused because linking not done
gcc: ext/extinit.o: linker input file unused because linking not done
gcc: ext/bigdecimal/bigdecimal.a: linker input file unused because
linking
not done
gcc: ext/curses/curses.a: linker input file unused because linking not
done
gcc: ext/dbm/dbm.a: linker input file unused because linking not done
gcc: ext/digest/md5/md5.a: linker input file unused because linking not
done
gcc: ext/digest/rmd160/rmd160.a: linker input file unused because
linking
not done
gcc: ext/digest/sha1/sha1.a: linker input file unused because linking
not
done
gcc: ext/digest/sha2/sha2.a: linker input file unused because linking
not
done
gcc: ext/iconv/iconv.a: linker input file unused because linking not
done
gcc: ext/openssl/openssl.a: linker input file unused because linking not
done
gcc: ext/zlib/zlib.a: linker input file unused because linking not done
gcc: -lruby-static: linker input file unused because linking not done
gcc: -ldld: linker input file unused because linking not done
gcc: -lcrypt: linker input file unused because linking not done
gcc: -lm: linker input file unused because linking not done
gcc: -lcur_colr: linker input file unused because linking not done
gcc: -ltermcap: linker input file unused because linking not done
gcc: -lssl: linker input file unused because linking not done
gcc: -lcrypto: linker input file unused because linking not done
gcc: -liconv: linker input file unused because linking not done
gcc: -lnsl: linker input file unused because linking not done
gcc: -lz: linker input file unused because linking not done
gmake[1]: Leaving directory `/home/tnordloh/ruby/ruby-1.8.4'

And that really loses me.  It looks a lot like the 'gcc' command got
garbled.  Any idea what to make of that? I don't see an explicit
'failed'
message, but did it run right?  I can't tell.
One thing is for sure, ri still isn't working:

root@atcito01 [/home/tnordloh/ruby/ruby-1.8.4]
# ri Array
/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
Tim Nordloh (Guest)
on 2006-03-22 17:07
(Received via mailing list)
These first couple of lines look like a malformed gcc command to me.
Anyone
have an idea of what the line should read?





gcc -g -O2  -DRUBY_EXPORT -DYYMAXDEPTH=300   -Wl,-E -L.

-L"/usr/local/include/openssl/lib" -E  main.o ext/extinit.o
ext/bigdecimal/bigdecimal.a ext/curses/curses.a ext/dbm/dbm.a
ext/digest/md5/md5.a ext/digest/rmd160/rmd160.a ext/digest/sha1/sha1.a
ext/digest/sha2/sha2.a ext/iconv/iconv.a ext/openssl/openssl.a
ext/zlib/zlib.a -lruby-static -ldld -lcrypt -lm  -lcur_colr -ltermcap
-lssl
-lcrypto -liconv -lnsl -lz -o ruby

gcc: -E: linker input file unused because linking not done
Mauricio F. (Guest)
on 2006-03-22 17:30
(Received via mailing list)
On Thu, Mar 23, 2006 at 12:07:30AM +0900, Tim Nordloh wrote:
> These first couple of lines look like a malformed gcc command to me.  Anyone
> have an idea of what the line should read?
>
> gcc -g -O2  -DRUBY_EXPORT -DYYMAXDEPTH=300   -Wl,-E -L.
> -L"/usr/local/include/openssl/lib" -E  main.o ext/extinit.o
                                    ====
Could you try without this?

> ext/bigdecimal/bigdecimal.a ext/curses/curses.a ext/dbm/dbm.a
> ext/digest/md5/md5.a ext/digest/rmd160/rmd160.a ext/digest/sha1/sha1.a
> ext/digest/sha2/sha2.a ext/iconv/iconv.a ext/openssl/openssl.a
> ext/zlib/zlib.a -lruby-static -ldld -lcrypt -lm  -lcur_colr -ltermcap -lssl
> -lcrypto -liconv -lnsl -lz -o ruby

BTW, you might have to add digest (which digest/md5 and friends depend
on)
and syck (in order to get ri to work) to the extension list.
Tim Nordloh (Guest)
on 2006-03-22 19:44
(Received via mailing list)
Ok, I hand-modified it and ended up with this....
 gcc -g -O2  -DRUBY_EXPORT -DYYMAXDEPTH=300   -Wl,-E -L.
main.oext/extinit.o ext/bigdecimal/bigdecimal.a \
> ext/curses/curses.a ext/dbm/dbm.a ext/digest/md5/md5.a
ext/digest/rmd160/rmd160.a ext/digest/sha1/sha1.a \
> ext/digest/sha2/sha2.a ext/iconv/iconv.a ext/openssl/openssl.a
ext/zlib/zlib.a -lruby-static -ldld -lcrypt \
> -lm  -lcur_colr -ltermcap -lssl -lcrypto -liconv -lnsl -lz -o ruby

which seemed to run successfully.

So, I went through and removed all references to the
"/usr/local/include/openssl/lib" from all MakeFiles.  I still got an
error,
so I ended up removing the "EXTLDFLAGS" entry (which contained the extra
-E
which was causing the compile failure.  I was then able to successfully
run
the 'gmake' routine, as well as 'gmake all'.

Thanks, this is the closest I've managed to get, but all that work

"gmake install-all" appeared to successfully run, but I continue to get
the
same error when I attempt to 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

So what is the problem?
MenTaLguY (Guest)
on 2006-03-22 21:48
(Received via mailing list)
I really think this approach of removing things until it compiles is a
mistake; if you did eventually get something that built, you'd just end
up with a build of Ruby that most likely won't run any useful Ruby
scripts.

Your main issue is one of how the libraries Ruby depends on were built
or installed -- you definitely do want to build them yourself, if you're
currently trying to use prepackaged versions.  Part of the what's going
on is missing header files, but I have no idea what else is going on.
If you build the libraries yourself with the default options (to the
degree possible), they're a known quantity.

I actually created a /usr/local/ruby where I installed fresh builds of
all the required libraries.  Note that doing so will required compiling
everything with e.g. -Wl,+b -Wl,/usr/local/ruby/lib though...

Also, see my notes in the earlier post:
 http://groups.google.com/group/comp.lang.ruby/brow...

I have to ask, though -- do you really need to do this on _HP-UX_?

For me, it was almost more pain than it was worth -- not because of
adjustments required to Ruby itself, but because of quirks of the
platform and the gymnastics required to build the libraries Ruby depends
on in just the right way to make the dynamic linker happy.

-mental
Tim Nordloh (Guest)
on 2006-03-22 23:46
(Received via mailing list)
Well, my basic Ruby scripts run ok for my basic needs, and no -- I don't
'need' to run Ruby on HP-UX.  I'm the System Admin: I'll just label it
as a
'non HP-UX compliant product' and tell any developer that wants to use
it to
use Perl for their interpreted language needs :)

I'll just wait until some bright-eyed kid gets a version on the HP
Software
porting archive.

Thanks all, for the attempts....
MenTaLguY (Guest)
on 2006-03-23 00:34
(Received via mailing list)
On Thu, 23 Mar 2006 06:46:28 +0900, "Tim Nordloh" 
<removed_email_address@domain.invalid>
wrote:
> I'll just wait until some bright-eyed kid gets a version on the HP
> Software porting archive.

I guess that really means getting correctly built versions of all the
relevent libraries on the porting archive first.

Once that were done, building Ruby proper is trivial aside from the
usual HP-UX porting tricks like short-circuiting the autoconf test to
ignore HP-UX's incompletely implemented getaddrinfo().

Does anyone else on the list care enough for me to pursue this?

-mental
Benjohn B. (Guest)
on 2006-03-23 01:15
(Received via mailing list)
On 22 Mar 2006, at 22:34, MenTaLguY wrote:

> to ignore HP-UX's incompletely implemented getaddrinfo().
>
> Does anyone else on the list care enough for me to pursue this?

I desperately need a version of Ruby that works on HPUX, and I've
really got very little idea of how to go about getting it to work :
( - I'm from the happy world of opening my iBook, and "oooh, it's pre-
installed!", all this needing to download things, tinker with them,
and build them, is totally alien!

:) If you can get it to work, and you live in London, I'm happy to
pay in beer :)
Tim Nordloh (Guest)
on 2006-03-23 04:05
(Received via mailing list)
MenTaLGuY,
I'd love to get Ruby working on HP-UX, but more importantly I would like
to
generate a series of steps that can be easily duplicated to install Ruby
on
HP-UX anywhere.  Of course, this is mostly to benefit me, so it's very
easy
to convince me to stop bugging the entire Ruby community about it :).
As I
mentioned in my original post, the directions out there right now are
just
too high-level for me.

I'm willing to help out in whatever way possible in getting a procedure
set
up.

If this helps, In the final analysis, I was getting the same failure on
all
libraries except one.  I couldn't link 'crypto' on most, and 'iconv' on
the
odd one.  I was able to verify this by purging references to 'crypto' in
the
makefiles, at which point everything except iconv successfully linked.
Give
me a hint as to what library I need for this.  I actually see crypto.h
in
the /usr/local/etc/openssl directory, is there another version I need?

For some reason I still get SYCK errors at this point which, I assume,
means that one of the libraries needs something I messed up by removing
crypto linking and not dynamically linking iconv.

If you have something else for me to try, I'll be glad to.
James G. (Guest)
on 2006-03-23 04:13
(Received via mailing list)
On Mar 22, 2006, at 8:05 PM, Tim Nordloh wrote:

> I'd love to get Ruby working on HP-UX, but more importantly I would
> like to
> generate a series of steps that can be easily duplicated to install
> Ruby on
> HP-UX anywhere.

What I believe MenTaLguY was trying to say is that you would need to
sit down and do a bunch of compiling to get it going.

Those C extensions link against other libraries on the system.  For
some reason, this isn't working out for your build process.  It could
be because you don't have the needed library installed, or just that
your package-manager installs aren't recognized, possibly because of
missing header files.

By pulling those libraries down yourself and building them from
source, you can probably get around at least a large portion of
this.  However, that's not likely to boil down to a simple series of
steps.

James Edward G. II
Tim Nordloh (Guest)
on 2006-03-23 05:13
(Received via mailing list)
At this point, I'm not asking for a lot, just a hint would help, such
as,
what library is crypto in (openssl I guess????  I'm attempting to
compile
that now, so hopefully my guess is right), and what library is iconv in?
And which one is likely the hangup for YAML+SYCK?

I'm trying my best to not waste anyone's time, and for every response
I've
spent at least an hour checking, rechecking deleting and reinstalling
from
scratch (honing the mysterious procedure), and I have made several
discoveries on the way.  I thank everyone for advice so far and
understand
if you all want to give up.  After all, I'm not exactly paying anyone
for
their time.  That's kind of why I keep talking about creating a
lower-level
procedure for an HP-UX install, so that the Ruby community will at least
be
able to gain some benefit at the end of this thread.
MenTaLguY (Guest)
on 2006-03-23 05:53
(Received via mailing list)
libcrypto is provided by openssl, yes

iconv _should_ be provided by your OS's libc, but as I recall HP-UX's is
present but broken (HP has a distressing habit of implementing things
just enough to pass a naive configure test).  You can get a portable
iconv replacement for Ruby to use here:

 http://www.gnu.org/software/libiconv/

If I remember correctly, the list of essential libraries is something
like (in no particular order):

 - zlib
 - libgdbm
 - libiconv
 - ncurses
 - readline
 - openssl

I think there's one more I'm forgetting, but I can't find my notes just
now.  It'll be pretty obvious if you're still missing one, though.

Make sure that these are all available as either shared libraries, 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
Tim Nordloh (Guest)
on 2006-03-23 06:36
(Received via mailing list)
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 <removed_email_address@domain.invalid> 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
Alexey V. (Guest)
on 2006-03-23 06:42
(Received via mailing list)
MenTaLguY wrote:

>
About a year ago, the major problems for me in building Ruiby on HP-UX
was libpthread.

Reason: an HPUX process that wants to use libraries compiled as
multithreaded (case in hand: the Oracle DB driver), must be compiled as
multithreaded itself. Unfortunately, Ruby didn't work when compiled in
multi-threaded mode on HP-UX. It did compile fine and dandy without
libpthread, but then I couldn't use it for half the tasks I needed it to
perform.

Alex
MenTaLguY (Guest)
on 2006-03-23 19:03
(Received via mailing list)
On Thu, 23 Mar 2006 13:36:34 +0900, "Tim Nordloh" 
<removed_email_address@domain.invalid>
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
Tim Nordloh (Guest)
on 2006-03-23 20:14
(Received via mailing list)
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.
Tim Nordloh (Guest)
on 2006-03-23 20:36
(Received via mailing list)
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.
4.  run "gmake all" in base ruby directory
5.  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 :)
Tim Nordloh (Guest)
on 2006-03-30 22:42
(Received via mailing list)
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
3. run configure with these options
  --with-openssl-dir=/usr/local/ssl/
  --with-iconv-dir=/usr/local
  --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"

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


<sigh> 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?
MenTaLguY (Guest)
on 2006-03-30 23:04
(Received via mailing list)
On Fri, 31 Mar 2006 03:41:24 +0900, "Tim Nordloh" 
<removed_email_address@domain.invalid>
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 (Guest)
on 2006-03-30 23:43
(Received via mailing list)
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?
Simon Kröger (Guest)
on 2006-03-30 23:59
(Received via mailing list)
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
MenTaLguY (Guest)
on 2006-03-31 00:30
(Received via mailing list)
On Fri, 31 Mar 2006 04:41:54 +0900, "Tim Nordloh" 
<removed_email_address@domain.invalid>
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
Tim Nordloh (Guest)
on 2006-03-31 02:44
(Received via mailing list)
looks like gcc version 3.4.3, and HP's ld, version B.11.41
MenTaLguY (Guest)
on 2006-03-31 20:28
(Received via mailing list)
On Fri, 31 Mar 2006 07:41:39 +0900, "Tim Nordloh" 
<removed_email_address@domain.invalid>
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
MenTaLguY (Guest)
on 2006-03-31 20:38
(Received via mailing list)
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
Tim Nordloh (Guest)
on 2006-04-02 08:39
(Received via mailing list)
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...
James G. (Guest)
on 2006-04-02 19:47
(Received via mailing list)
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
This topic is locked and can not be replied to.