Re: Help regarding migration from Oracle 9i client lib to Oracle 10g client lib.
Date: Sat, 23 Aug 2008 21:00:42 +0200
"som" <esunil_at_gmail.com> schreef in bericht
> Hi Friends,
> We are using Oracle client libraries to connect Oracle databases
> through our application with a shared library, and I am new bie in
> We have two separate environments/machines(HP-UX-11.11) one is for DEV
> and one is for SIT.
> And so we have two separate oracle 10g client installations.
> But when we build and use the shared library it works absolutely fine
> without any issue/doubt in DEV.
> And although everything is same on both ENV, still it's frequently
> generating core at SIT.
> Core back trace is as per below:
> Where SMAC2000.sl is our application based shared library and
> libtclntsh.sl.10.1 is one of the oracle client library.
> Now as there is no respective libclntsh10.a exists, and also we are
> not referring this library during build. However it seems there is
> some internal calls for this library. And when we have compared size
> then we found that both libs differ in size in both ENV.
> But as it's just a doubt not sure. so humbly request you to all of you
> to kindly assist on the same.
> Please let me know If more information is required to assist on the
> ORACLE LIBS USED TO BUILD APPLICATON SHARED LIBRARY->
> -L$CS_LIB -l:libtcora.sl -L$ORA_LIBDIR -lsql10 -lclient10 -lcommon10 -
> -lnls10 -lcore10 -lclntst10 -l:libcma.sl -lcl -l:libm.sl -l:libcl.a -L/
> usr/lib -l:libdce.sl -L/usr/
> lib -l:libdld.sl -l:libm.sl -l:libcma.sl"
> CORE BACK TRACE->
> #0 0xc005deec in pthread_mutex_lock+0x68 () from /usr/lib/libpthread.
> #1 0xe4db2f20 in sltsini+0x2c () from /rciti35/cs35/dll/SMAC2000.sl
> #2 0xe7021d44 in slxmxinit+0x14 () from /rciti35/oracle/lib32/
> #3 0xe4d54e94 in lxzinit+0x38 () from /rciti35/cs35/dll/SMAC2000.sl
> #4 0xe70aac10 in lpminitm+0x80 () from /rciti35/oracle/lib32/
> #5 0xe4dd57c8 in lpminit+0x24 () from /rciti35/cs35/dll/SMAC2000.sl
> #6 0xe70a0cac in LhtIntCreate+0x68 () from /rciti35/oracle/lib32/
> #7 0xe49018a4 in kpummpin+0x14c () from /rciti35/cs35/dll/SMAC2000.sl
> #8 0xe6440f60 in kpupin+0x7c () from /rciti35/oracle/lib32/
> #9 0xe43dcf90 in OCIInitialize+0x30 () from /rciti35/cs35/dll/
> #10 0xe633fb84 in sqgctx+0xc4 () from /rciti35/oracle/lib32/
> #11 0xe43a0ce8 in sqgrct+0x50 () from /rciti35/cs35/dll/SMAC2000.sl
> #12 0xe6325a70 in sqlcmex+0x3e0 () from /rciti35/oracle/lib32/
> #13 0xe6326074 in sqlcxt+0x78 () from /rciti35/oracle/lib32/
> #14 0xe4391ac8 in sql_connect () conn=0x6fff3828 ../cpref/tcoragsl.c:
> #16 0xe438b0c4 in exec_ext_mgmt (p_ExtCredentials=0x6fff2938)
> at /SSO_lib/user/shirishp/cs35/c/ora_app.c:267
> #17 0x94b8 in adm_process_rec+0x848 ()
> #18 0x8a60 in process_pwd_requests+0x3cc ()
> #19 0x85b4 in adm_do_ext_sync+0x5c ()
> #20 0x7f5c in main+0x7ac ()
> Thanks in advance,
If your database is 64 bit (you did not mention thatm but I guess it is), you must change your library path, since it seems it's looking in lib32. I have seen this problem recently in environments that were upgraded from 9i to 10g, since the library path is set to 32 bits during installation. Furthermore, you may have to install the companion CD, if you did not do that already. Looks like you have an external procedure call in C, which may require the companion CD software.
Shakespeare Received on Sat Aug 23 2008 - 21:00:42 CEST