Re: PRO*C compile with librarires

From: Scott <nospam_at_nomail.com>
Date: Fri, 12 Jan 2007 11:01:46 -0500
Message-ID: <PhOph.53342$9i3.266063@wagner.videotron.net>

"hpuxrac" <johnbhurley_at_sbcglobal.net> wrote in message news:1168521946.150909.142860_at_77g2000hsv.googlegroups.com...
>
> Scott wrote:
>> Hello All,
>>
>> I know next to nothing about pro*c so hopefully someone can point me in
>> the
>> right direction, I am not even sure what to search for so I will try and
>> explain it in my own words.
>>
>> A pro*c application was compiled such that it uses oracle libraries found
>> under a given path. Now when they move that app binary to another server
>> with an oracle client install it does not run because the oracle client
>> is
>> installed in a differnet location. Does that mean that the proc app was
>> compiled statically such that the libs are hard coded into the binary?
>> How
>> do you get around this sort of thing short of having all installation use
>> the same path. I was hoping that it would use some type of relative path
>> assuming I had my ORACLE_HOME var set, but apparently not. I am using
>> HPUX
>> 11.11 with oracle 10.2.0.2
>>
>> Thanks
>> Scott
>
> Are you working with your pro c developers on this one?
>
> Do a file command and a chatr on the executable and send us the output.
>
> What does the shell script that you used to compile and link the
> executable look like?
>
> You should be able to relink the executable or re-compile it. What
> standards are in place in your organization for setting up the
> environment for pro c usage?
>

This is the first time I heard of any application using pro c, so I am not aware of any standards around it.

hp172[none](oracle): > ldd PPc1

        /usr/lib/libc.2 =>      /usr/lib/libc.2
        /usr/lib/libdld.2 =>    /usr/lib/libdld.2
        /usr/lib/libc.2 =>      /usr/lib/libc.2
        /pkg1/oracle/product/10.2.0/lib32/libclntsh.sl.10.1 => 
/pkg1/oracle/product/10.2.0/lib32/libclntsh.sl.10.1
        /usr/lib/libcl.2 =>     /usr/lib/libcl.2
        /usr/lib/libisamstub.1 =>       /usr/lib/libisamstub.1
        /usr/lib/libdld.2 =>    /usr/lib/libdld.2
        /usr/lib/libc.2 =>      /usr/lib/libc.2
        /usr/lib/libm.2 =>      /usr/lib/libm.2
        /usr/lib/libdld.2 =>    /usr/lib/libdld.2
        /usr/lib/libnss_dns.1 =>        /usr/lib/libnss_dns.1
        /usr/lib/libdld.2 =>    /usr/lib/libdld.2
        /usr/lib/libpthread.1 =>        /usr/lib/libpthread.1
        /usr/lib/librt.2 =>     /usr/lib/librt.2
        /pkg1/oracle/product/10.2.0/lib32/libnnz10.sl => 

/pkg1/oracle/product/10.2.0/lib32/libnnz10.sl

hp172[none](oracle): > file PPc1
PPc1: PA-RISC2.0 shared executable dynamically linked -not stripped

hp172[none](oracle): > chatr PPc1
PPc1:

         shared executable
         shared library dynamic path search:
             SHLIB_PATH     disabled  second
             embedded path  disabled  first  Not Defined
         shared library list:
             dynamic   /pkg1/oracle/product/10.2.0/lib32/libclntsh.sl.10.1
             dynamic   /usr/lib/libc.2
         shared library binding:
             deferred
         global hash table disabled
         plabel caching disabled
         global hash array size:1103
         global hash array nbuckets:3
         shared vtable support disabled
         explicit unloading enabled
         static branch prediction disabled
         executable from stack: D (default)
         kernel assisted branch prediction enabled
         lazy swap allocation disabled
         text segment locking disabled
         data segment locking disabled
         third quadrant private data space disabled
         fourth quadrant private data space disabled
         third quadrant global data space disabled
         data page size: D (default)
         instruction page size: D (default)
         nulptr references disabled
         shared library private mapping disabled
         shared library text merging disabled

If you have any comments/links about what should be in a standards document that would be helpful.

I have alot of reading to do this weekend.

thanks Received on Fri Jan 12 2007 - 10:01:46 CST