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.
