[clue] shared lib question -> java

[mike havlicek]

Hello,

Thanks for the input. So in theory could LD_LIBRARY_PATH be used
with a daemon owner to get a server application to use
an alternate glibc suite? I suspect serious problems as Matt eluded.

This thing was built with oracle8i,java2:1.4, and apache 1.ancient components (httpd/tomcat). A crippling thing is that I only have compiled class files for some critical pieces (only enough source to generate frustration and surely the database connector trickery is compiled in to talk to oracl8i hampering my import flexibility :). Being mostly ignorant in things JAVA I suspect that my only hope to get any of it to run is to use a java kit at or near the level that was used to generate the class files? This is where I discovered the lib problem: attempting to check the version of the jdk/jre components included...  java -version barfed about the  libstdc++ shared lib -> glibc2.ancient) Eventually discovering it was
some 1.4.0-beta kit. Although, resorting to  my vast programming 
experience I coded "hello world", javac'd it with the ancient kit and the resulting class file worked with a 1.6.0_24-b07 kit blowing my subjective theory of "how things won't work as advertised/or how I think they ought to" out of the water.. :) I figured platform independence only goes so
far as having the right kit version on your platform....? I guess it 
might be pretty backwards compatible...which I didn't want to count on
messing around with something way broken.


I have back peddled to just setting up a rh7.3 vmware vm if I actually want to investigate this mess.

Thanks again,

-Mike 



--- On Thu, 3/24/11, Matt Dew <marcoz at osource.org> wrote:

> From: Matt Dew <marcoz at osource.org>
> Subject: Re: [clue] shared lib question
> To: clue at cluedenver.org
> Date: Thursday, March 24, 2011, 4:22 PM
> On 03/24/2011 04:02 PM, dennisjperkins at comcast.net
> wrote:
> > There is also a LIBPATH variable (I don't recall the
> exact name) that
> > you might be able to use instead of modifying
> ld.so.conf.
> 
> LD_LIBRARY_PATH
> 
> 
> >
> > ----- Original Message -----
> > From: "Matt Dew" <marcoz at osource.org>
> > To: clue at cluedenver.org
> > Sent: Thursday, March 24, 2011 10:02:33 AM
> > Subject: Re: [clue] shared lib question
> >
> > On 03/24/2011 07:35 AM, mike havlicek wrote:
> >  > Hello All,
> >  >
> >  > I am looking at an old custom app (fubar)
> in my frankenlab and have
> > questioned a rigging scenario I am about to try. I am
> very rusty on
> >  > manually setting up shared libraries so I
> thought I would throw this
> >  > out to the group for suggestions.
> >  >
> >  > The scenario is that I have app pieces that
> require
> >  > libstdc++-libc6.1-1.so.2 and I am building
> my model OS as a
> >  > CentOS5.5 xen guest. First I don't know if
> this library is
> >  > available in one of the canned rpm sets for
> CentOS 5.5? I really
> >  > don't want to meddle with some rpm
> dependency chaos through the target
> >  > distro mixing chocolate with peanut butter
> to do my app fubar discovery
> >  > testing.
> >  >
> >  > I have discovered that this library was in
> rh7.2 so I was thinking
> >  > of doing a quick dirty copy from a rh7
> system into some custom area
> >  > on my CentOS 5 and add an entry to
> ld.so.conf -> ldconfig and
> >  > see what happens.
> >  >
> >  > I can't remember how the symlinks say to
> the .2 get setup (manual,through
> >  > config ...)?
> >  >
> >
> > I've had _bad_ things happen when doing copying libs
> around and doing
> > symlinks, (granted that was for glibc stuff), but
> still....
> >
> > Don't forget
> > ldd libstdc++-libc6.1-1.so.2 to figure out any
> dependencies.
> >
> >
> > Good luck!
> >
> >  > Thanks for suggestions as I do review,
> >  >
> >  > -Mike
> >  >
> >  >
> >  >
> >  >
> _______________________________________________
> >  > clue mailing list
> >  > clue at cluedenver.org
> >  > http://cluedenver.org/mailman/listinfo/clue
> >
> > _______________________________________________
> > clue mailing list
> > clue at cluedenver.org
> > http://cluedenver.org/mailman/listinfo/clue
> >
> >
> >
> > _______________________________________________
> > clue mailing list
> > clue at cluedenver.org
> > http://cluedenver.org/mailman/listinfo/clue
> 
> _______________________________________________
> clue mailing list
> clue at cluedenver.org
> http://cluedenver.org/mailman/listinfo/clue
>