-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
(Just discovered how to type é on my Mac's keyboard.. no more copy/paste for you name!) 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. The issue is that the tomcat5 install (or a related package, or even someone manually installing tcnative) 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. > 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. 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. > 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. > 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 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. > (*) 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. > (And I am quite sure that the way I am guessing above is going to > make some Real Programmers cringe, and wonder how I have been able > to survive for 30+ years in this world not knowing this kind of > stuff.) Close Enough (tm). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7qUkUACgkQ9CaO5/Lv0PDVaQCeNCatm6T7YGB8LUfwEsnCRdcG ZAIAniwIWVOUBx9sF5O7xh5xEkJzHREg =yg64 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
