On 29.04.2011 16:31, Daniel Faber wrote: > wow, awesome post with great detailed explanations which I am very > interested in because we had a similar problem. I have just one
Thanks! > I've read chapter 3.9 "Loading Native Code Libraries" in the OSGi spec > again and it seems the framework is not required to unpack all of a > bundle's native libs into the same directory. But the procedure you > describe relies on this, doesn't it? Right! I figured I'd leave that out to not make matters worse for now. I actually had to develop such a fallback mechanism for just that case and even reported a bug when Felix changed its cache layout (https://issues.apache.org/jira/browse/FELIX-1731), so the problem is definitely real. :) In that case the only way out is to first try $ORIGIN and, failing that, a fixed location like /tmp or any other directory to which your bundle can unpack the libraries and try again. It's much more difficult to get right since you really want to clean up afterwards, not clash with other instances of your bundle on the same machine (need a cooperative locking mechanism) etc. It's also worth noting that the entire $ORIGIN workaround (it's not a hack, it's a feature! :) does NOT work when the app is running SUID/GUID root, but a) that's bad anyway and b) neither will LD_LIBRARY_PATH, for security reasons. Probably the biggest problem is the fact that the DT_RUNPATH is very limited in size. A truly dynamic & secure solution would be to rewrite the DT_RUNPATH ELF header from Java so that the path is short, but private (pid or short random token)..sort of like bytecode weaving, but for shared libraries. :) Porting the necessary patchelf bits to Java as OSGi service would make for an awesome student project! > BTW: The spec says: > It is not uncommon that native code libraries have dependencies on other > native code libraries. This specification does not support these > dependencies, it is assumed that native libraries delivered in bundles > should not rely on other native libraries. ..and then reality sets in. It's outside the spec, but clearly not feasible when you want to integrate 3rd-party libraries or even things built in a larger context. > Now the feature request I like to discuss: Doesn't sound "too wrong" :) but is probably again in the area of framework-dependant implementation details. As Richard says your best bet would be to bring this up on the public osgi-dev list. There was a long-standing bug in the OSGi bugzilla about native dependencies, but I think it is dormant or dead. It's just very hard to get this right. cheers Holger --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
