Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 12/12/11 8:27 PM, Caldarale, Charles R wrote:
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: path used
for tc-natuve
And if I do this, where do I put the result, in such a way that
it doesn't overwrite the existing one used by tomcat5.5 ?
One would normally place it in Tomcat's bin directory, and set
LD_LIBRARY_PATH or -Djava.library.path to point there. It's a bit
scary (and rude) to put it in a public place.
+1
I think Andre's original problem wasn't with tcnative, but with
libapr. If you build the new tcnative dynamically-linked, then you're
going to have the same problem.
Other possibilities include building everything (libapr and
libtcnative) and putting them into, say, CATALINA_HOME/bin. I recently
had a fun (read: miserable) time doing this with 2 versions of each
(total of 4 possibilities) along with 2 libssl versions at the same
time. Trying to trump the system-level libraries requires that you
cover all your bases, otherwise some library name (like
libapr.1.4.2.so) will not override /usr/lib/libapr.1.so. Make sure
you've got all your symlinks right :)
Well, yes. And that's exactly why, for the time being, I have decided to do without
tc-native. The first line I saw in the tc-native source README was something like "to
build, you may need OpenSSL xx .." and then I started getting cold feet, remembering my
previous experiences going along the dependencies-from-hell route umpteen times before.
And in this case, we're talking indeed about a system which already has all those nice
symlinks all over the place..
What is it he said ? "once you give in to the dark side of the Force, forever dominate you
it will.."
If apt-get is the dark side, then I guess I'm already on Darth's side.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
