tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: path used for tc-natuve
Date Fri, 16 Dec 2011 10:13:32 GMT

thanks. You provided the missing pieces.

Christopher Schultz wrote:
> 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 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
2) add a line
to the script which starts Tomcat, prior to the actual Tomcat start line.

1) gives the option to the JVM, and the JVM will then pass this to dl_open() when it calls
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:
For additional commands, e-mail:

View raw message