Native Development

[canurabus]

Hey,

I'm trying to compile OpenSceneGraph for the PlayBook. It's a C++ library and the PlayBook already has all the key dependencies available. The project itself uses CMake for its build system, where you can specify paths for dependencies and which compilers to use. I matched up all the necessary paths using the tools available in the NDK. Right now I'm just trying to get a build working for the Simulator, so I used the ntox86-g++ compiler.

Building the library (I built it as a static lib) works fine. Linking an application against the library however gives me the following output:

(.rodata._ZTVN9osgViewer22GraphicsWindowEmbeddedE[_ZTVN9osgViewer22GraphicsWindowEmbeddedE]+0xcc):-1: error: undefined reference to `non-virtual thunk to osgViewer::GraphicsWindow::requestRedraw()'

osgViewer::GraphicsWindow::requestRedraw() is a virtual function that's also been implemented (ie not pure virtual). I read online that the "undefined reference to non-virtual thunk" is a compiler/linker bug that happens when you compile the library and your project with different optimization flags. I made sure the same optimization flags are always passed to the compiler.

Here's a sample compiler call for my project (this is using qmake defaults for ndk -- it calls qcc with ntox86):

qcc -Vgcc_ntox86 -lang-c++ -Wl,-rpath-link,/home/preet/bbndk-2.0.1/target/qnx6/x86/lib -Wl,-rpath-link,/home/preet/bbndk-2.0.1/target/qnx6/x86/usr/lib -Wl,-O1 -o qml_osg_viewport main.o qdecviewport.o moc_qdecviewport.o    -L/home/preet/bbndk-2.0.1/target/qnx6/x86/lib -L/home/preet/bbndk-2.0.1/target/qnx6/x86/usr/lib -L/usr/local/Trolltech/QtLighthouse-4.8.2-i386/lib -lstdc++ -lc -L/home/preet/Dev/scratch-blackberry/qml_osg_viewport/deploy/lib/osg_sim -losgViewer -losgGA -losgDB -losgUtil -losg -lOpenThreads -lQtDeclarative -L/usr/local/Trolltech/QtLighthouse-4.8.2-i386/lib -L/home/preet/bbndk-2.0.1/target/qnx6/x86/lib -L/home/preet/bbndk-2.0.1/target/qnx6/x86/usr/lib -lQtScript -lQtSvg -lQtSql -lQtXmlPatterns -lQtNetwork -lsocket -lQtOpenGL -lQtGui -lQtCore -lm -lbps -lGLESv2 -lEGL 

Here's an example of how CMake from OpenSceneGraph calls the compiler:

/home/preet/bbndk-2.0.1/host/linux/x86/usr/bin/ntox86-g++   -DOSG_LIBRARY_STATIC -O1 -Wall -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused -fpermissive -I/home/preet/Downloads/Packages/dirty/openscenegraph-git/include -I/home/preet/bbndk-2.0.1/target/qnx6/usr/include/GLES2 -I/home/preet/Downloads/Packages/dirty/build/include    -o CMakeFiles/osgdb_pvr.dir/ReaderWriterPVR.obj -c /home/preet/Downloads/Packages/dirty/openscenegraph-git/src/osgPlugins/pvr/ReaderWriterPVR.cpp

Note that both use the same optimization level. I'm assuming that 'ntox86-g++' is the same thing as 'qcc -Vgcc_notx86 -lang-c++'. I'm at a loss of how to troubleshoot this any further. There are a bunch of open source projects up on the BlackBerry github that use CMake so this should work -- OpenSceneGraph has also been ported to Android and iOS as well. I'd appreciate any advice.

[anhu]

Hi, 

I noticed the fiollowing in your compiler line: 

-L/usr/local/Trolltech/QtLighthouse-4.8.2-i386/lib

Not sure if this has anything to do with your problems, but when cross compiling, it should never be referencing libs in /usr/local

[canurabus]

Thanks for the reply.

I've simply installed the relevant Qt libs in /usr/local/Trolltech... it shouldn't pose an issue.

[anhu]

Yes, but where did you get those QT libs? Were they built for the playbook simulator or were they just general x86 binaries? 

[canurabus]

They were built specifically for the Playbook Simulator. I followed the instructions available on the qt-project website to build the libs (and I've tested / successfully deployed other sample applications to both the simulator and device so I think the Qt libs are in working order)

[canurabus]

Small follow up. While I'm still unable to get OpenSceneGraph to run on the PlayBook, I was able to compile/link successfully by modifying OpenSceneGraph's source. I think the issue might be with the tool chain's compiler (I'm using the 2.0.1 NDK which includes GCC 4.4.2) with respect to a specific situation in C++ where you have multiple inheritance and virtual functions. GCC 4.7 was able to link without any modifications to the source which further suggests its compiler related.