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


> 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.


To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to