To All, This seems like a good suggestion by Tim on having the compilier/linker ignore errors with Weak (or as in my case doesn't exist symbols. It is undefined). Anyone know how to make gcc and/or perl do this??? I've been working on this for 3 days and can't seem to find the answer.
It's a shame, everything is clean and the "make test" still hangs on these few lines of code. I've even done a export LD_PRELOAD=/ora01/app/oracle/product/10.2/jre/1.4.2/lib/PA_RISC/libjava.sl Nothing.. Same error Thank You 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. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Tim Bunce <[EMAIL PROTECTED]> 12/13/2007 04:22 PM To Richard T Malafa/DEF/[EMAIL PROTECTED] cc Alexander V Alekseev <[EMAIL PROTECTED]>, dbi-dev@perl.org, [EMAIL PROTECTED], Joseph E Schmalhofer/DEF/[EMAIL PROTECTED] Subject Re: ANNOUNCE: DBD::Oracle 1.20 Release Candidate Google suggests that Jv_registersClasses is a 'weak symbol' so shouldn't cause errors if undefined. That suggests there's a problem with your compiler/linker configuration. Tim. On Thu, Dec 13, 2007 at 03:18:16PM -0500, Richard T Malafa wrote: > 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. > >
