Brilliant, the LD_PRELOAD does the trick. Many thanks. Andy. At 16:53 04/09/01 -0500, you wrote: >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 > > > >_______________________________________________ > >Pam-list@redhat.com >https://listman.redhat.com/mailman/listinfo/pam-list
