Re: PRO*C compile with librarires

"hpuxrac" <johnbhurley_at_sbcglobal.net> wrote in message news:1168620780.431662.233950_at_l53g2000cwa.googlegroups.com...
>
> Scott wrote:
>> "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.
>
> If your organization is developing and supporting pro c applications
> then you need some kind of standards. How to compile, options to use,
> how to link, options to use, how to migrate these applications from
> various environments, etc.
>
> It's the basic programmers and system administrator concerns here.
>
>>
>> I have alot of reading to do this weekend.
>
> All the relevant clues are in the output that you just sent from ldd
> and chatr.
>
> It's a busy day today otherwise I would elaborate a little more.
>
>>
>> thanks
>
> There's got to be some sites around hosting pro c information for
> oracle that include most of the stuff you need to figure out. We don't
> use any of it here it's been a bunch of years ( since my Andersen
> Consulting gig ended ) that I was an oracle dba at a place with much
> usage of it.
>
> Who did the developing for this application? What do they know? You
> might want to start with that and get some background from them.
>

They were the ones that said I needed to have the oracle libs in the same location on all servers, otherwise they would have to recompile etc. The previous client environments were created with an ORACLE_HOME of /pkg1/oracle/product/10.2.0 however, when I installed the client on the new server I called it /pkg1/oracle/product/10.2.0/client ( made sense to me at the time ). I was not involved with this project from the start I just inherited it so I didn't setup the other servers and my standard is to always name the home eg client, db, asm, crs etc. In the end I removed the home and re-installed it to the location they were looking for as that only took about 30 minutes and now all is well.

Now my personal goal is to see if this can be done. I did see some sites that talked about adding a search path using chatr +b however, I am not sure if that is going to work in this case. I will keep digging as it has been a while that I dug into something that was so foreign to me. It is sort of like going back to school.

thanks again
Scott. Received on Fri Jan 12 2007 - 14:37:45 CST