Christopher,
thanks. You provided the missing pieces.
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
(Just discovered how to type é on my Mac's keyboard.. no more
copy/paste for you name!)
Thanks for the effot. ;-)
It's getting better every year that passes. Until a couple of years ago, I was used to
see my name spelled as "Andr" followed by various CP-1282 graphic symbols.
On 12/15/11 1:15 PM, André Warnier wrote:
This left me intellectually unsatisfied, because I still did not
know how Tomcat6 was finding this old tc-native, and there is
nothing really obvious in the documentation which explains where it
is looking. (Probably because to Real Java Programmers, this is too
obvious; but I am not a Real Java Programmer).
This has almost nothing to do with Java... it's just the way *NIX
loaders perform shared-library resolution.
I should add, because it seems to have a bearing here, that this
Tomcat6 is started by a script in /etc/init.d copied and adapted
from the one for Tomcat5.5, which means that it actually runs under
the jsvc wrapper. That may influence how the search for the
tc-native library is effected, and I may have to to do something to
tell jsvc to look in the (CATALINA_HOME)/bin directory of Tomat6
first. Or not, because as mentioned above, I have no idea really
how this all works.
No, the wrapper is not relevant.
Ok, that's cleat to me now.
The issue is that the tomcat5 install
(or a related package, or even someone manually installing tcnative)
It was the Debian "apt-get install tomcat5.5", I'm sure.
put the native library into /usr/lib, which is a very special place.
It's like someone parking their car in your "guest" space -- it's rude
and causes confusion, but it's not the end of the world: you just have
to park someplace else.
Right. That's one of the much-debated inconvenients of working with package managers. You
never quite know where they will put things or why.
And in this case, putting it in a common place like /usr/lib is really debatable, since I
don't think that anything else but Tomcat uses that library.
And finally, according to other recommendations on the list which
appear to be worthy of trust, I believe that if, in the script
which starts Tomcat6, I would add something like export
LD_LIBRARY_PATH=/opt/tomcat6/bin:$LD_LIBRARY_PATH that might do the
trick as far as tc-native is concerned.
Probably, but it would be better (if possible) to move the offending,
outdated tcnative library into the tomcat5 deployment so everyone is
separate.
Yes, but then "uninstall" and "upgrade" and so on won't work anymore..
IIRC, Tomcat loads tcnative without a version number in it's name even
when it prefers a version that is of a certain level. That's not a
great practice, but I'm not sure there's anything that can be done
given that evidently there have been breaking-changes with
non-obviously-breaking version-number bumps.
Ok, so that indirectly explains another thing which I had separately been wondering about
: why on all those *NIX systems, there are always a profusion of symlinks in the */lib
directories, pointing to the same .so file, but with different names.
But when I examine the environment of the running Tomcat5.5, it
does not seem to have LD_LIBRARY_PATH defined, so I am puzzled
again.
Look at the man page for "ld" which ought to give you the default for
your system. /usr/lib is certainly in there.
So let me make a partly-educated guess, and someone here can tell
me how far off the mark I am.
Tomcat6 is Java code, so when it looks for a library, it actually
asks the JVM to find it. The JVM is native code, so it looks along
it's own "library path" to find the desired module. (*)
Yes, but it's just a coincidence that the JVM is native :)
But the JVM being wrapped by the jsvc wrapper, it falls down to the
jsvc wrapper to look along its own library path for the module, in
an attempt to satisfy the JVM. (**)
Probably not. jsvc is the parent process, so it probably dictates
things such as environment variables, but it's not going to get
delegated requests for library loading. That's the OS's job invoked
directly by the JVM.
I was suspecting that, but it's nice to see it confirmed.
And when native code under Linux is looking for a library, this is
probably done through some other standard library providing
"library loading" functions.
This is a *NIX thing. I'm sure Microsoft Windows does things in a
similar way.
And that's where Chuck's (so to speak) dlopen() comes in.
Slowly the dawn comes.
And this "library loading library" probably looks first at which
search path is contained in the LD_LIBRARY_PATH variable, prior to
searching in some other path provided in it's own configuration
data.
I think LD_LIBRARY_PATH is it. If not set, there is a default.
Still coming along nicely..
(*) but maybe Tomcat has told it to look first in CATALINA_HOME/bin
? (**) or maybe jsvc does not intervene at all, and it is the JVM
which talks directly to the "library loading library" ?
Tomcat does not do this by default. You must explicitly configure
java.library.path to point to CATALINA_HOME/bin if you want it to load
native libraries from there.
Ahaaa. /That/ was the key missing piece.
So, if I compile the tc-native library, and put the resulting libtcnative-1.so in
(catalina_home)/bin, that by itself is not enough to have Tomcat find it there.
Right ?
And in order for Tomcat6 to find it there, I need to do either one of 2 things :
1) add an option "-Djava.library.path=$CATALINA_HOME/bin" to the command-line that starts
the JVM which runs Tomcat
OR
2) add a line
export LD_LIBRARY_PATH=$CATALINA_HOME/bin:$LD_LIBRARY_PATH
to the script which starts Tomcat, prior to the actual Tomcat start line.
and
1) gives the option to the JVM, and the JVM will then pass this to dl_open()
when it calls it
or
2) is something that dl_open() itself will find and add to it's default search path when
it is called by the JVM
Have I got it now ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
