Andy Hutchinson <andy@extensible.co.uk> writes: > So to my question; I've not written any code to load libpam.so so why > does it fail when running under Java/JNI? When you are running your C testbed, the main application has been linked with -lpam. So libpam.so is included in the list of libraries for resolving externals in subsequent calls to dlopen(). > There has been some discussion on the list that it's down to the Java > loadLibrary call but I don't think this is the case. If the loadLibrary > call doesn't set the RTLD_GLOBAL flag to dlopen then it just means that > the particular library cannot be used for further symbol resolution. This > is fine as there are no symbols to resolve other than the single point of > entry. Yes, but it is not _just_ that library that won't be used for further symbol resolution. None of the libraries that IT relies on will be consulted either. So libpam is loaded in memory, but not in the search list. You could get around this by forcing java to use RTLD_GLOBAL, or perhaps setting LD_PRELOAD before launching your java app. Something like: LD_PRELOAD=/usr/lib/libpam.so java foo.jar -bp -- Ceterum censeo vi esse delendam
