Alex,
I went over the information again. Jv_registersClasses is undefined in
everywhere on the HP UX machines. I can hardly believe that no one has
solved this problem since I see things like below for HP machines. I've
even tried doing DBI from source and I get the Jv_registersClasses error.
I got an C++ error example but this is not C++. It can't be the Java
Libraries since there are no "sl" or "so" files in those anymore. And
what the heck is the Java Jv_registers error doing in c or c++ anymore???
I checked every perl binary I could find for HP UX and in every case it's
not defined. I wouldn't know what a definition of Jv_registersClasses
looks like if it bit me.
I do have
[EMAIL PROTECTED]> find / -name "libstdc*"
/opt/hp-gcc64-4.2.0/lib/libstdc++.a
/opt/hp-gcc64-4.2.0/lib/libstdc++.la
/opt/hp-gcc64-4.2.0/lib/libstdc++.sl.6.9
/opt/hp-gcc64-4.2.0/lib/libstdc++.sl
/opt/hp-gcc64-4.2.0/lib/libstdc++.sl.6
[EMAIL PROTECTED]
I don't think any of these are being called by 'make test', but I can't
prove that..
pm> des 77
====================
Package 77:
Name: DBI
Version: 1.53
Author: Tim Bunce ([EMAIL PROTECTED])
Title: DBI
Abstract: Database independent interface for Perl
Location: ActiveState
Available Platforms:
1. PA-RISC2.0-thread-multi-LP64-5.8
====================
ppm>
Package 82:
Name: DBI-Shell
Version: 11.94
Author: Thomas A. Lowery ([EMAIL PROTECTED])
Title: DBI-Shell
Abstract: Interactive command shell for the DBI
Location: ActiveState
Prerequisites:
1. IO-Tee 0.0
2. Text-Reform 0.0
Available Platforms:
1. PA-RISC2.0-thread-multi-LP64-5.8
====================
Other information on using the new 1.20 RC4 version of DBD. It's much
cleaner. Lot of minor errors are now gone. I also put in the export
LDOPTS="+s -L/usr/local/lib -L/usr/lib" for the environment which
certainly helps..
I'm going to reload the newer version of gcc 4.2.2 with the newer binary
utils in a bit. But somehow someone has the knowledge of how to fix my
problem. I'm thinking it's a simple solution along the lines of fixing
that +b $ error in the original perl Makefile.PL No one has updated the
doc on this yet.
This is all the errors that are left and repeating all through "make
test". Everything else is cleaned up..
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_Jv_RegisterClasses' in
load module '/opt/perl_64/lib/5.8.8/PA-RISC2.0-th
read-multi-LP64/auto/Cwd/Cwd.sl'.
t/01base................/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol
'_Jv_RegisterClasses' in load module '/opt/perl_64
/lib/5.8.8/PA-RISC2.0-thread-multi-LP64/auto/Cwd/Cwd.sl'.
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_Jv_RegisterClasses' in
load module '/opt/perl_64/lib/5.8.8/PA-RISC2.0-th
read-multi-LP64/auto/List/Util/Util.sl'.
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_Jv_RegisterClasses' in
load module '/opt/perl_64/lib/5.8.8/PA-RISC2.0-th
read-multi-LP64/auto/List/Util/Util.sl'.
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_Jv_RegisterClasses' in
load module '/Xtra/pwork/DBD-Oracle-1.20-RC4/blib
/arch/auto/DBD/Oracle/Oracle.sl'.
Failed to load Oracle extension and/or shared libraries:
install_driver(Oracle) failed: Can't load
'/Xtra/pwork/DBD-Oracle-1.20-RC4/blib/arch/auto/DBD/Oracle/Oracle.sl' for
module
DBD::Oracle: Unresolved external at
/opt/perl_64/lib/5.8.8/PA-RISC2.0-thread-multi-LP64/DynaLoader.pm line
230.
at (eval 7) line 3
Compilation failed in require at (eval 7) line 3
Thank You for your Help.
Rich
• '•..• '•. ><((((º> .• '•. .• '•. •. .• '•. ><((((º>
“Anything that doesn’t eat you today is saving you for tomorrow.”
Computer Sciences Corporation
Registered Office: 2100 East Grand Avenue, El Segundo California 90245,
USA
Registered in USA No: C-489-59
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Alexander V Alekseev <[EMAIL PROTECTED]>
12/04/2007 04:59 PM
To
Richard T Malafa/DEF/[EMAIL PROTECTED]
cc
dbi-dev@perl.org, [EMAIL PROTECTED]
Subject
Re: ANNOUNCE: DBD::Oracle 1.20 Release Candidate
Hello!
On Tue, 4 Dec 2007, Richard T Malafa wrote:
> Hi Alex,
> Yes, I remember that...
>
> > It's rather bad, that you get this error. I suppose, that the
> > someone needs to fix DynaLoader perl object port to HPUX. You should
> > probably
> > submit this bug (with Cwd for simplicity) to official Perl5 bug list.
> > See http://rt.perl.org/perlbug/ .
>
> I should have added more to my statement.
>
> There is more than just perl.
>
> I've looked at a lot of 64 bit modules and none of them seem to define
the
> _Jv_RegisterClasses problem. I don't know why it is that way.
>
> Here's the other problem:
>
> I have to use the HP binary since it is already one with a gcc compiler
> and other features that we use here. In addition it does contain
working
> dbi 1.5 and all the corrections everyone wanted in the past is done. (as
> far as I know. I haven't found one not corrected).
>
> Even though the make perl works just fine after that code correction.
I'm
> going to try to combine the 64 bit and 32 bit libraries (even though we
> don't use them anymore) and see what happens.
>
> It's just so heartbreaking when the make test fails so bad right off the
> bat.
>
> Last but not Least important. We have to use standard binaries as much
> as possible since most compiling (if not all) is forbidden at the remote
> site due to security reasons.
I've done some research on the problem. As we noticed,
this
symbol is marked "WEAK UNDEF" in symbol list. If you google for "weak
symbol", you'll find two definitions of the term. For example:
------------ From wikipedia: -------------
weak symbol is a symbol definition in an object file or dynamic library
that may be overridden by other symbol definitions.
------------------------------------------
But Linux "man 1 nm" says:
---------- man 1 nm ----------
"V" The symbol is a weak object. When a weak defined symbol is linked
with a normal defined symbol, the normal defined symbol is
used with no error. When a weak undefined symbol is linked and
the symbol is not defined, the value of the weak symbol becomes
zero with no error.
-------------------------------
And here
http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl17?a=view
we find long and detailed explanation of weak symbols.
Please notice, that meaning of "WEAK" is different depending
on whether the symbol is defined:
---- Solaris 10 Linker and Libraries Guide ----
...
Symbol Resolution
...
Symbols that undergo resolution can have either a global or weak
binding. Within relocatable objects, weak bindings have lower precedence
than global binding. Relocatable object symbols with different bindings
are resolved according to a slight alteration of the basic rules.
...
In symbol resolution, weak defined symbols are silently overridden by
any global definition of the same name.
...
Undefined Symbols
...
Weak Symbols
Weak symbol references that remain unresolved, do not result in a fatal
error condition, no matter what output file type is being generated.
If a static executable is being generated, the symbol is converted to an
absolute symbol with an assigned value of zero.
If a dynamic executable or shared object is being produced, the symbol
is left as an undefined weak reference with an assigned value of zero.
During process execution, the runtime linker searches for this symbol.
If the runtime linker does not find a match, the reference is bound to
an address of zero instead of generating a fatal relocation error.
Historically, these undefined weak referenced symbols have been employed
as a mechanism to test for the existence of functionality. For example,
the following C code fragment might have been used in the shared object
libfoo.so.1:
#pragma weak foo
extern void foo(char *);
void bar(char * path)
{
void (* fptr)(char *);
if ((fptr = foo) != 0)
(* fptr)(path);
}
When building an application that references libfoo.so.1, the link-edit
completes successfully regardless of whether a definition for the symbol
foo is found. If during execution of the application the function
address tests nonzero, the function is called. However, if the symbol
definition is not found, the function address tests zero and therefore
is not called.
---------------------------------------------
As you see, compiler has put weak undefined reference to
_Jv_RegisterClasses for some reason. This should guarantee that
program would run even with undefined symbol _Jv_RegisterClasses.
And it seems to work even at your HPUX!
But, if you try to load some dynamic library explicitely
(via dlopen() call), you have a choice whether to specify
RTLD_LAZY or RTLD_NOW mode. The first is the default mode in perl
binary. But if you choose to use the second flag,
all undefined symbols in the library are resolved before
dlopen() returns.
For Linux & Solaris symbols this requirement doesn't
include WEAK symbols. But for HPUX does, as I see in your case.
In perlrun manual PERL_DL_NONLAZY environment variable is
described like this:
------------------------------------------
PERL_DL_NONLAZY
Set to one to have perl resolve all undefined symbols when it loads a
dynamic library. The default behaviour is to resolve symbols when
they are used. Setting this variable is useful during testing of
extensions as it ensures that you get an error on misspelled function
names even if the test suite doesn't call it.
------------------------------------------
It is implemented as specifying RTLD_NOW mode for all
dlopen() calls.
For Linux & Solaris it works even for libraries with
WEAK UNDEF symbols. But HPUX fails.
I pointed you to Cwd.so module which is supplied with OS
perl
binary to show you that the problem is not in DBD::Oracle module.
This is the problem in compiler or perl port to HPUX. Or
even
both. I don't think that the problem may be solved locally in
DBD::Oracle module.
You have workaroud (as described in
README-files/hpux/libjava.eml document).
You mentioned, that 64-bit moduled do not have such
trouble.
But 32-bit & 64-bit environments are completely different. It's not
a surprize to me that 64-bit subsystem does not have a reference
to _Jv_RegisterClasses.
You cannot use 64-bit and 32-bit libraries in the same
process. It's impossible.
Finally, you have 4 choises:
1) Fix
PERL_DL_NONLAZY=1 perl -e 'require Cwd; import Cwd; print cwd(),"\n"'
by using different perl binary.
2) Use workaround. Or do not run make test. (and hope it works)
3) Port DBD::Oracle module to 64-bit.
4) Write your own library with _Jv_RegisterClasses symbol defined
and always use LD_PRELOAD option, if HPUX supports it.
Bye. Alex.
