Hi, I just discovered a very odd and - at least for my use case very unhelpful - change in behaviour of felix from 1.8 to 2.0 concerning native libraries.
You might know about the difficulties of managing libraries with dependencies. For my project I had pursued the approach of handling Linux platforms by temporarily copying dependencies to /tmp, loading them by making the originally loaded JNI library have an RPATH of /tmp, and then clean up. This is ugly, error-prone, insecure (symlink attack) etc. but *worked* across all runtimes. In order to improve this rather ugly hack I now tried to use an RPATH of "$ORIGIN". This special value will make shared libaries look in the location of the originating dependency, which is _exactly_ what I want for bundles. And it works great! There is a slight catch that not all runtimes unpack bundle libraries eagerly, so the libs have to be referenced in order to show up in the bundle cache. Works fine too...except on felix 2.0. For some reason a bundle's libraries are unpacked with any path given in the NativeCode header (correct and good) but _into another subdirectory_. This means that three libraries platform/a.so, platform/b.so, platform/c.so will not end up in a common directory platform/ but rather in directories platform/0/, platform/1/, platform/2/ and so on - which totally breaks the great $ORIGIN hack. :( Is there a good reason why felix would need to do this? Older versions did not, and neither does equinox (at least not 3.5). I fully realize that the layout of the bundle cache is "hands off" and an implementation detail, but at this level I _must_ have some deterministic way of interacting with the platform. IMHO it is wrong that resources or libraries with common path prefixes do not actually end up in a common directory - not technically, but in the "principle of least surprise" way. Ideas or comments? I can help fix this if necessary. thanks Holger
