Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Web and WebWorks Development

Thank you for visiting the BlackBerry Support Community Forums.

BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)

BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.

"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."

- Kevin Michaluk, Founder, CrackBerry.com

Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.

Posts: 12
Registered: ‎02-17-2012
My Device: developer
My Carrier: developer
Accepted Solution

Blackberry10 Webworks / Native Extension Bug (?)

Has anyone seen simulator messages like:


Require Error Can't find


Library cannot be found


when booting an html5 webworks app with a native extension. 


Although I am seeing this error,

1) I know that my deployment archive (*.bar file) has included my shared library because I can see it in the archive  under

/native/plugins/jnext/bp.so along with an expected auth.txt file,

2) I know that the deployment process in fine because I can copy the $SDK_DIR/Framework/ext/bbm.platform/simulator/bbm.so library to overwrite my bp.so library (also in a subdir of Framework/ext), do a rebuild and deploy. Then on booting my app, I get a message that bp.Memory can not be instantiated.. Which is fine, That tells me that my index.js file is loading the fake bp.so (good) but cant invoke the Memory class (expected, as it didnt  exist in bbm.so before the copy).

3) I know my C++ code is fine as I have an exact copy of the code in TEMPLATE (Memory) example C++ extension which I downloaded from github. 

4) I believe the shared library is fine as it built without issues in the IDE, downloaded from the C++ section of the developers tools. (Im using the Linux version and building with the default, device-debug settings). 


But, then, there has to be something wrong with the library because the system cant load it from the /native/plugins/jnext directory in the application folder. So, at the moment I'm suspecting that there is an integration issue somewhere between the various tools involved, the IDE, the SDK, the simulator.


Has anyone else had luck with native extensions for BB10 html5 webworks apps?


Posts: 12
Registered: ‎02-17-2012
My Device: developer
My Carrier: developer

Re: Blackberry10 Webworks / Native Extension Bug (?)

I have had a little more time to play with this this morning and have been able to track down what is going on so...


For other developers who run into this. The reason this happens is that the Device-Debug or Device-Release profiles in the IDE produce a ELF 32 bit ARM shared libraries, while the Simulator-Debug or Simulator-Release profiles produce ELF 32 bit Intel 80368 shared libraries. Deponding on the target its important to therefore get the appropriate library.


For RIM, you have a somewhat unintegrated toolchain and I understand the limitations that you are under. On the other hand I have had to spend time reverse engineering that toolchain to figure out how it works. That reverse engineering work is not something that you generally are going to want to push downstream. Additionally, this thread is one but not the first usability issue I have run into with your tools . As a professional developer, wasted time on usability issues is very difficult to charge for (-ie: not cost effictive to develop for) nor is it pleasurable (-ie: it rots the brain). So I knowing what I do I would probably not take on work in the future related to BB development...

I think a fair estimation of where RIM stands in terms of development experience is  --- not on par with your competitors. I hope that can change as it really is in  the best interest of everyone that RIM is a successful part of the mobile market.