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.
>

This link could be useful to some people

http://docs.hp.com/en/5966-9887/ch02s07.html

if chatr allows me to add a search path after the binary has been linked I think I might have been able to get around my problem. Received on Fri Jan 12 2007 - 14:50:21 CST