Error in resolve using Bundle-NativeCode

[Jan Henrik Wiesner]

For using native libs in my bundle i have added to following to my bnd file

Bundle-NativeCode: native/JKeyCatcher.dll;osname=Win32;osname=Windows Server 2008 R2;processor=x86;processor=x86_64,native/libJKeyCatcher.so;osname=linux;processor=x86

When resolving the bndrun file i get the following error.

Unable to resolve <<INITIAL>> ver=null: missing requirement (osgi.identity=Device_Keyboard) [caused by: Unable to resolve Device_Keyboard ver=1.0.1.SNAPSHOT: missing requirement (|(&(|(osgi.native.osname~=Win32)(osgi.native.osname~=Windows Server 2008 R2))(|(osgi.native.processor~=x86)(osgi.native.processor~=x86_64)))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86)))]
org.osgi.service.resolver.ResolutionException: Unable to resolve <<INITIAL>> ver=null: missing requirement (osgi.identity=Device_Keyboard) [caused by: Unable to resolve Device_Keyboard ver=1.0.1.SNAPSHOT: missing requirement (|(&(|(osgi.native.osname~=Win32)(osgi.native.osname~=Windows Server 2008 R2))(|(osgi.native.processor~=x86)(osgi.native.processor~=x86_64)))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86)))]
    at org.apache.felix.resolver.Candidates.populateResource(Candidates.java:285)
    at org.apache.felix.resolver.Candidates.populate(Candidates.java:153)
    at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:148)
    at biz.aQute.resolve.ResolveProcess.resolve(ResolveProcess.java:34)
    at org.bndtools.core.resolve.ResolveOperation.run(ResolveOperation.java:46)
    at org.bndtools.core.resolve.ResolveJob.run(ResolveJob.java:38)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

I am using bndtools 2.1.0.RC2-20130423-173628.
I has worked with 2.0.0

[Jan Henrik Wiesner]

When using a wild card at the end of the bundle native declaration, like

Bundle-NativeCode: native/JKeyCatcher.dll;osname=Win32;osname=Windows Server 2008 R2;processor=x86;processor=x86_64,native/libJKeyCatcher.so;osname=linux;processor=x86,*

This works, no suprise.

[Neil Bartlett]

You need to tell the resolver which platform you want to resolve for.
Obviously the resolver should reject this bundle when you are
resolving for (say) MacOS, since there is no native code entry for
that platform (unless you add the trailing wild-card, naturally). You
can achieve this by setting the -runsystemcapabilities header. For
example to resolve for Win32/x86 set the following in your bndrun:

-runsystemcapabilities: osgi.native; osgi.native.osname=Win32;
osgi.native.processor=x86

Alternatively if you want to resolve for the same platform that you
are currently running Bndtools on, use the ${native_capability} macro:

-runsystemcapabilities: ${native_capability}

Regards
Neil

> --
> You received this message because you are subscribed to the Google Groups
> "bndtools-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bndtools-user...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ferry Huberts]

@Jan

Can you put a page explaining this on our wiki please?
(https://github.com/bndtools/bndtools/wiki)
That way others can find it more easily.

@Neil, IMHO we should start thinking about writing some more
documentation for bndtools that also covers these kinds of issues. Not a
very sexy job though :-(

> --
> Ferry Huberts

[Jan Henrik Wiesner]

Hi Neil,

thanks for your quick response.

On Thursday, April 25, 2013 11:05:54 AM UTC+2, Neil Bartlett wrote:

You need to tell the resolver which platform you want to resolve for.

Yes this seems quite logical.
 

Obviously the resolver should reject this bundle when you are
resolving for (say) MacOS, since there is no native code entry for
that platform (unless you add the trailing wild-card, naturally). You
can achieve this by setting the -runsystemcapabilities header. For
example to resolve for Win32/x86 set the following in your bndrun:

    -runsystemcapabilities: osgi.native; osgi.native.osname=Win32;
osgi.native.processor=x86

 
Yes this works for me :-).

Alternatively if you want to resolve for the same platform that you
are currently running Bndtools on, use the ${native_capability} macro:

    -runsystemcapabilities: ${native_capability}

It seems that the macro does not work properly, i get

Unrecognised/unsupported processor name 'amd64' in ${native} macro., for cmd: native_capability, arguments; [native_capability]

Regards
Jan

[Neil Bartlett]

Ah. This sounds like a bug, I will investigate. To help me, could you
please let me know what the following Java snippet prints on your
machine please:

System.out.println(System.getProperty("os.arch"));
System.out.println(System.getProperty("os.name"));
System.out.println(System.getProperty("os.version"));

Many thanks,
Neil

>
> Regards
> Jan

[Ferry Huberts]

My machine:
amd64
Linux
3.8.8-202.fc18.x86_64

>> Regards
>> Jan
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "bndtools-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to bndtools-user...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>

> --
> Ferry Huberts

[Neil Bartlett]

I checked a fix into "next", but it's hard for me to be absolutely sure it works since my own machine reports "x86_64". Ferry could you try this out please?

Unfortunately this is too late for 2.1, which is releasing *today*. It will be in 2.2, or we might consider cutting a 2.1.1 if there are some other minor fixes to make available. As a workaround you will have to explicitly state the osgi.native capability in your bndrun file. 

Neil

--
Neil Bartlett
Sent from a phone

[Alexander]

I checked a fix into "next", but it's hard for me to be absolutely sure it works since my own machine reports "x86_64". Ferry could you try this out please?

Unfortunately this is too late for 2.1, which is releasing *today*. It will be in 2.2, or we might consider cutting a 2.1.1 if there are some other minor fixes to make available. As a workaround you will have to explicitly state the osgi.native capability in your bndrun file. 

I ran into this problem today as well. The system was a Win32 system with Windows7, the cpu is also reported as amd64. I updated to the latest development build, and that solves the issue, so maybe a bit late, but this problem is solved.