HelpWanted | NativeCodeFinder only finds libraries from the host bundle

[krooq]

Hi,

I'm trying to load a library from a fragment using the Bundle-NativeCode header.
The library fails to load, when I debug all the way through I find that the NativeCodeFinder seems to only return library paths from the host bundle in its findBundleNativeCode method.
My guess is that the nativeCode.get(0) sections in the method are just a typo or something that should instead refer to the moduleWire loop variable but that's just a guess.

This is all I can discern and tbh I don't really know if I'm even doing it right.
It seems odd that this feature would be broken since a main use case for fragments is this loading of different native libs..
There doesn't seem to be any documentation on how to configure the Bundle-NativeCode hearder differently for a fragment compared to a regular plugin so I just assume its the same but there are only 2 SO articles kind of related to this problem and they don't seem to provide concrete solutions.

EDIT: Extra info
In my case I have a host bundle that has a linux and windows binaries
i.e.

Bundle-NativeCode: lib/JOGL/natives/linux-amd64/libgluegen-rt.so;
  osname=linux;
  processor=x86_64,
 lib/JOGL/natives/windows-amd64/gluegen-rt.dll;
  osname=win32; 
  processor=x86_64,
 *

And multiple fragments but only one with native libs, and only for windows
i.e.

Bundle-NativeCode: libs/chrome_elf.dll;
 libs/jcef.dll;
 libs/libcef.dll;
  osname=win32; 
  processor=x86_64,
 *

As there are multiple libs it never hits the first case and always falls through to the second indexResult.
Since the getNativePaths method only ever returns the attributes of the requirement from the first ModuleWire (the host bundle) I don't see how it could ever return something from a fragment. However as @merks has shown, clearly it can so I must be misunderstanding part of the code.

EDIT 2: It is also not working in the dev environment so the build properties isn't the issue I don't think.

[merks]

This works for me:

It's processing this bundle:

https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.jreinfo.win32.x86_64

You could use this automated setup to create a development environment with a working example:

https://ci.eclipse.org/oomph/

Maybe you show what you've done so someone might spot the problem.

Something as simple as forgetting to mentioned the library in the bin.includes of the build.properties will be a problem, at least in the final deployed build:

https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.jreinfo.win32.x86_64/build.properties

[krooq]

Thank you so much for this detailed response and the example!
I'm going to dig in a bit more with this to try figure out why this works but mine doesn't. Really appreciate it.

[krooq]

@merks in your example the host bundle doesn't have a Bundle-NativeCode header of its own, is that a requirement for fragments providing native code?

[merks]

I don't know what the constraints are, but I did expect that only a fragment would have such a thing (because why install something that can't be used) but I didn't know about all the general filtering capabilities such a declaration could use...

[tjwatson]

I'll try to get a testcase going that exercises what I suspect may be a bug. But there could be multiple fragments also that have the Bundle-NativeCode header and it seems the paths would only get returned for the first fragment found. Having Bundle-NativeCode header in the host and a single fragment would also seem to be the same problem.

[tjwatson]

It would be good to get a testcase that exhibits this issue. Could it be that you have multiple fragments? Or that you have Bundle-NativeCode headers in the host and the fragment? I must say that I don't recall why nativeCode.get(0) is used there as that would use the paths from the first native code requirement. But if you have multiple ....

[krooq]

I do indeed have Bundle-NativeCode headers in both the host and fragment, is this an issue?
I'll try find the time to make a clean test case.

[tjwatson]

This indeed a real issue and I have a possible fix going in #238 Thanks @krooq for opening the issue. Your original debugging analysis in #236 was correct.

I wish that issue had not been converted to a discussion so swiftly. @laeubi I'm not sure why that original issue is now locked from when you converted it to a discussion. Can you unlock and reopen that original issue #236?

[laeubi]

@tjwatson You can just click on the ... of a comment in this discussion and choose "Reference in new issue" I think that would be the quickest solution, or you simply reference the original issue in your PR, I think it does not matter much if it is closed already.