topic Re: Compiling Perl Modules in Operating System - HP-UX

Compiling Perl Modules

CelesteG — Tue, 31 Mar 2009 23:43:06 GMT

I am trying to compile the DBD::Oracle module one of our systems (HP-UX 11.23 PA-RISC 64-bit running an Oracle 10g client)with no success. I've run into a few errors that I've been able to solve with the help of google like the 'could not open message catalog' and 'this option is available only with the C/ANSI C product'. This latest error, however has me stumped. I'm running into this when I do the 'make' for DBD::Oracle...

------------------
cc: "Oracle.xsi", line 277: warning 524: Cast (non-lvalue) appears on left-hand side of assignment.
cc: "Oracle.xsi", line 277: error 1549: Modifiable lvalue required for assignment operator.
cc: "Oracle.xsi", line 336: warning 524: Cast (non-lvalue) appears on left-hand side of assignment.
cc: "Oracle.xsi", line 336: error 1549: Modifiable lvalue required for assignment operator.
*** Error exit code 1

Stop.

---------------------

...and I can't seem to get past this. I installed the latest DBI with the 'perl Makefile.PL/make/make test/make install' commands and it worked fine but following that same process with DBD::Oracle module fails at the 'make' step with the above error.

I am not the least bit fluent when it comes to Perl so I am completely and utterly clueless on how to resolve this. Am I missing an env variable, a patch maybe???? They system was built off of DVDs from the Sept. 2008 release of HP-UX 11.23. Thanks so much for any help that will get me closer to fixing this issue.

Celeste

Re: Compiling Perl Modules

Dennis Handly — Wed, 01 Apr 2009 00:32:13 GMT

cc: "Oracle.xsi", line 277: warning 524: Cast (non-lvalue) appears on left-hand side of assignment.
cc: "Oracle.xsi", line 277: error 1549: Modifiable lvalue required for assignment operator.

What's on line 277 and 336? It could be an evil macro.

Re: Compiling Perl Modules

CelesteG — Wed, 01 Apr 2009 01:29:49 GMT

Line 227 and 336 both contain the following line from the Oracle.xsi:

DBIc_CACHED_KIDS(imp_dbh) = Nullhv;

Here is the entire if statement that uses that line:
/* pre-disconnect checks and tidy-ups */
if (DBIc_CACHED_KIDS(imp_dbh)) {
SvREFCNT_dec(DBIc_CACHED_KIDS(imp_dbh)); /* cast them to the winds */
DBIc_CACHED_KIDS(imp_dbh) = Nullhv;
}

I played around with that line by commenting it out and then replacing it with a line that had 'Nullhv' changed to 'NULL' and 'Null'. Neither worked.

Re: Compiling Perl Modules

CelesteG — Wed, 01 Apr 2009 01:36:58 GMT

apologies, I meant

'Line 277.....'

Re: Compiling Perl Modules

Dennis Handly — Wed, 01 Apr 2009 10:18:53 GMT

>DBIc_CACHED_KIDS(imp_dbh) = Nullhv;

This looks like an evil macro that may not be defined.

Compile with: ... -E -Wp,-C,-G > Oracle.I
Then look at those lines and look for DBIc_CACHED_KIDS.

Re: Compiling Perl Modules

CelesteG — Wed, 01 Apr 2009 22:52:27 GMT

Hi Dennis, thanks for your responses. I have been able to get past this issue, which was two fold. We run a vendor supplied application that includes their built version of perl. This perl would not work for our environment because it was not built to include threaded libraries. How did I come to this conclusion?

After repeated attempts failed using vendor supplied perl, I decided to see if system perl would install this module. I received the same Oracle.xsi message. Well, Mr. Handly as it turns out I wasn't doing a 'make clean' after my unsuccessful compiles. I did a 'make clean' and system perl compiled the module successfully. So I figure that my Oracle.xsi errors with DBICached_Kids was due to running a compile in an environment that was not clean. Yeah, I know, I kicked myself a couple of times, but not enough to actaully hurt. :-)

I went back to vendor supplied perl and attempted another compile (after a 'make clean'). It still didn't work but I did receive a different error messages. 'perl Makefile.PL' returned this warning...

WARNING: Oracle is built with multi-threading libraries
You will most likely need to rebuild perl from sources
with the following libraries: -lcl -lpthread

And this time when I did a 'make test' I received....

PERL_DL_NONLAZY=1 /opt/mincom/perl/perl_5_8_5/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/01base.t .............. # Test loading DBI, DBD::Oracle and version
t/01base.t .............. 1/6 /usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /usr/lib/libcl.2
/usr/lib/dld.sl: Exec format error

After a bit of googling, I checked the vendor supplied version of perl with the 'perl -V' command and it was not built with the threaded library options. Sooooo, for now we'll point things to system perl and let the vendor rebuild their perl and repackage their software instead of mucking around with it ourselves.

Again thanks for your help and responses.

Celeste