My point was really that it should "just work" and the fact it doesn't suggests problems with your tool chain.
Tim. On Tue, Dec 18, 2007 at 11:11:12AM -0500, Richard T Malafa wrote: > 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]> To Richard T Malafa/DEF/[EMAIL > PROTECTED] > cc Alexander V Alekseev <[EMAIL > PROTECTED]>, dbi-dev@perl.org, > 12/13/2007 04:22 PM [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. > > > >
