tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: path used for tc-natuve
Date Fri, 16 Dec 2011 10:13:32 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message