Precompiled HP-UX Binaries of Perl 5.6.1

[Ralph Grothe]

Has anyone using GNU's gcc (won't get a license for HP's ANSI C/C++ compiler) encountered similar idiosyncrasies regarding precompiled Binaries of Perl 5.6.1 from the HP-UX Ports collection?

On my other HP-UX boxes I used to compile Perl from the sources in stable.tar.gz using gcc.

This way I (almost) never have had any problems getting CPAN modules compiled.

Now I tried the precompiled Perl binary for HP-UX 11.00 for the first time, and constantly am running into trouble during the make run of any CPAN module that compiled smoothly with the Perl installation from the source tarball.

After the automated CPAN module installation aborted while installing the LWP bundle, I haven't been able to fix things manually (tempering with the Makefile etc.) for the various prerequisite CPAN modules.

Seems I will have to remove the depot and do my installation from source again, or has anyone come to terms with the unruly Perl-depot?

[Mark Greene_1]

we are running 5.6.1 with no problems. from swlist:

perl B.5.6.1.C Perl Programming Language


from perl -v:

# /opt/perl/bin/perl -v

This is perl, v5.6.1 built for PA-RISC1.1-thread-multi
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2001, Larry Wall

Binary build 627 provided by ActiveState Tool Corp. http://www.ActiveState.com
Built 21:42:53 Jun 20 2001


HTH
mark

[Christopher Caldwell]

HP's probably built the binaries differently that the options your using; I imagine they used their own compiler as well.

Your best bet is to build Perl yourself (no big deal, sound like you've done it before). After the stock build, the rest of the module builds should follow the initial Perl build.

[H.Merijn Brand (procura]

1st of all, let me state that I am *very* happy that HP has finally decided to ship a more modern perl than the previous 4.036 as found on /usr/contrib/bin and has also decided to make it installed by default.

2nd (for all here) 'perl -v' does not give you the information you want. For that, use 'perl -V' (the capital V and it'll show you all the questions you asked.

From the README.hpux (this is from the 5.7.3 version, out for some days now) one could read:

---8<---

=head2 Using perl as shipped with HP-UX

As of application release September 2001, HP-UX 11.00 is shipped with
perl-5.6.1 in /opt/perl. The first occurrence is on CD 5012-7954 and
can be installed using

swinstall -s /cdrom perl

assuming you have mounted that CD on /cdrom. In this version the
following modules are installed:

ActivePerl::DocTools-0.04 HTML::Parser-3.19 XML::DOM-1.25
Archive::Tar-0.072 HTML::Tagset-3.03 XML::Parser-2.27
Compress::Zlib-1.08 MIME::Base64-2.11 XML::Simple-1.05
Convert::ASN1-0.10 Net-1.07 XML::XPath-1.09
Digest::MD5-2.11 PPM-2.1.5 XML::XSLT-0.32
File::CounterFile-0.12 SOAP::Lite-0.46 libwww-perl-5.51
Font::AFM-1.18 Storable-1.011 libxml-perl-0.07
HTML-Tree-3.11 URI-1.11 perl-ldap-0.23

The build is a portable hppa-1.1 multithread build that supports large
files compiled with gcc-2.9-hppa-991112

If you perform a new installation, then Perl will be installed
automatically.

-->8---

As you can see, HP did use the modified GNU C-compiler from the GNUpro suite, in order to open up the binaries to the public, so they can add XS modules without the need of the HP compiler.

If you however *do* have the HP compiler, please feel free to recompile perl from the source tree. I've gone through great trouble to make both HP C-ANSI-C *and* gcc (both 32 and 64 bit) compile perl out of the box (at least for 5.7.2 and up).

Another thing you might notice from the -V output is that they've chosen to build a threaded perl, which might conflict with some other applications you want to glue to perl. If you rebuild perl from the source, reconsider this choice

[Ralph Grothe]

Hi procura,

I didn't realize HP is *at last* shipping HP-UX with a reference-aware Perl version (i.e. >= 5.X).
We got quite a few HP boxes recently and they all were preinstalled with Perl *4* in /usr/contrib/bin!!!

I got this Perl 5.6.1 binary from
http://hpux.asknet.de/
(a German mirror of the HPUX-Ports)

Usually I load the Config module to get a thorough overview of what got installed:

perl -MConfig -e 'map {printf "%-20s => %s\n", $_, $Config{$_}} sort
keys %Config'

But you may also have an "|x \%Config" in a debugger session "perl -MConfig -de0"

My binary obviously wasn't built with gcc:

# perl -MConfig -e 'print "$Config{cc}\n"'
cc

Btw, the README.hpux file seems to contain POD, so you probably will get a more decent formatting if you say
perldoc README.hpux ;-)

Unfortunately in the list of bundled modules aren't those which I need,
in particular Bundle::LWP, Crypt::SSLeay, DBD::Oracle

Especially the latter two have always caused me much grief when trying to install them on HP-UX.

I have to make asynchronus multi-LWP::UserAgent connections to a webserver that uses TSL/SSL encryption of one of our customers.
Because this customer is complaining about inacceptable response times in servicing requests wrote such a script to prove that our network, and components are ok.
From home I could prove that SSL-requests were serviced 10 times slower than pure HTTP.
But there I could instantly install everything on Linux, which works right from the start, whereas I almost despair with Perl on HP-UX (I don't get many needed modules compiled!)

Another candidate is DBD::Oracle which I need for my backup scripts.

I will grab a recent HP-UX application CDROM and see if I can find a recent Perl on it (btw. 5.7.X is still marked development at CPAN).

[H.Merijn Brand (procura]

Whoa there, there are a /lot/ of questions ... :)

If you get a perl from a mirror, you get the perl-core, that is: the perl binary together with the modules shipped with the source. If you however install it from the CD, you get the modules I stated in the README.hpux (for which I'm the maintainer currently), which should save you a lot of time and effort.

I use 'perldoc perllocal' to see what has been installed, but CPAN offers some other nice modules/util to find out.

$Config{whatever} can be tampered with (for more obscure but sometimes valid reasons), perl -V does only read from Config.pm. If you /realy/ need to be sure, you probably have to do a 'what perl' to detect what tools were used to build the perl binary.

README.hpux indead is POD, but on installation is translated into more readable (cough cough) text. either 'man perlhpux' or 'perldoc perlhpux' will provide a presentation of the info most users expect it (README.hpux still is the source I have to edit, and is always at hand so to speak)

I don't have SSL installed (yet), so I cannot build SSLeay.

For Oracle I strongly advise to take the more recent builds of DBI (1.21) and DBD-Oracle (1.12) for portability has been improved greatly since DBI-1.14

And yes, 5.7.3 is still experimental, but it's not long now till 5.8.0 (the nexxt stable release) will hit the world (release candidate RC1 is planned for 2002-04-08).

--8<--- my Oracle porting notes
Change Makefile ???/lib/libclntsh.sl to ???/lib/liboracle.a in all locations, -Wl,Bimmediate to -Bimmediate and it'll work
Before testing be sure to set ORACLE_USERID

perl -pi -e 's:/lib/libclntsh.sl:/lib/liboracle.a:g ; s/-Wl,-Bimmediate/-Bimmediate/g' Makefile
-->8--- HTH

I've just peeked in DBD-Oracle-1.12/README.hpux, and it looks like it needs some polishing and minor adjustments. I'll poke Tim with some patches.

[Ralph Grothe]

procura,

thanks for the hints regarding building of DBD::Oracle.
In fact I just downloaded from CPAN (still hesitate to let module CPAN have it done ;-) DBI-1.21.tar.gz, DBD-Oracle-1.12.tar.gz, which were the latest I saw.
Meanwhile in the background I have a make run after Configure of stable.tar.gz.
I peered in your README.hpux from the DBD::Oracle tarball and took the advice from there to say -lcl -lpthread $* when prompted for lib flags by Configure.
But unlike suggested the +z ccflag didn't work with gcc :-(

I also think I will have to rebuild openssl because again the precompiled libraries of openssl from the Ports server weren't willing to cooperate with gcc.
I can recall configuring and building (let alone the tests) openssl/openssh takes hours (too much cryptography involved I guess).

Unfortunately I need these crypto libs.

There is another CPAN module which I want to play with, i.e. Penguin, to run distributed Perl code in order to query all "my" servers.

Have you got experience with Perf::Arm from CPAN?
This too sounds interesting to me
(we have the midaemon and MWA running on our production servers).

[H.Merijn Brand (procura]

HP ANSI C '+z' => gcc '-fpic'
+Z -> -fPIC

They both stand for Position Independent Code (+Z is allowing huge offsets)

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xf3178ffa98a2d5118ff10090279cd0f9,00.html

and from

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x56a479bffde7d4118fef0090279cd0f9,00.html

HP's ANSI C gcc
-Aa (nothing)ANSI mode
-Ae -ansi Extended ANSI
+z -fpic Position independent code
+Z -fPIC Position independent code
+ESlit (nothing) Collapse identical strings
+O[1-4] -O[1-4] Optimisation levels
+Onolimit (nothing) Don't restrict optimisations

be careful with -ansi on modern gcc's, because it does *restrict* your code instead of extend it :

[Ralph Grothe]

procura,

thanks again for translating the ccflags to what gcc understands.

I haven't really hacked much in C (because I'm pampered by Perl) that's why I never got that acquainted with all the gcc switches.

Does this on the other hand mean, that I will have to recompile Perl (now with the -fpic option) altogether, which would be a pitty because after the final make install I was able to get installed all the (so far) non-critical CPAN modules (e.g. !~/dbd|ssl/i) automgically by the CPAN module, without any error croaks from gcc :-)
Well, I will be wiser after installation of these "critical" modules.

If I posted a partial dump of error messages from the make run of them could I bother you with it?
Perhaps I should open a new thread?

[H.Merijn Brand (procura · Accepted solution]

+Z/-fPIC (whatever the case) is *always* a good choice, because dynamic loading is made a lot easier, and static programs can deal with it too.

Libraries I build (GNU stuff and SleepyCat for example) I always alter to accept the +Z, so dynamic loaded programs can later also deal with it.

And, yes, I think you should recompile perl ;-P
OTOH, you can test with what you have right now, and wait a month for 5.8.0 which is much richer in stability and features (Unicode, 64-bitness, packing, IO handling ...), and save the time to build that version.

I've no knowledge (yet) of SSL stuff, but you might try opening a new thread with some error dumps. You've got I slight change I'll chime in again (if it has to ddeal with perl :)