Floo writes

Hi,

I am using parts of the upplay source code for my own project. The aim of my project is to get a simple GUI for controlling a renderer on a Raspberry Pi with LCD display. Because I need the framebuffer support I have to use Qt5.4 for my project.

In a first step I have tested my upplay project on a Linux PC. Eveything compiles and runs fine. Than I used cross compiling to compile my source code for the ARM processer. It complies without error, however if I run the executable on the Raspberry Pi the program stops when initialising the RenderingControl. The last debug info I get from libupnpp ist "Service::subscibe" and "Service::registerCallback" from libupnpp/service.cxx. The next steps on the Linux PC at this point are "Service::unregisterCallback" and "Service::unsubscribe". However these program steps will never be reached on the ARM processor. Why?

Does anybody has any idea what is going wrong? It seems that something went wrong when calling the libupnpp functions using Qt5.4 on ARM. I also tried to compile the upplay using Qt4.8 on RaspPi and it works perfectly. Any idea what happens if I use Qt5.4 and the library on ARM?

I am very thankful for every piece of advice!

medoc92 writes

Hi,

I just pushed a few fixes for typo-level issues which prevented out-of-the-box compilation with qt 5.2, but I have no idea what can go wrong with your arm/qt5.4 version, I’m afraid that you will have to add debug traces until you can see where things stop.

Floo writes

Ok, thanks. I will try to run upplay on Qt5.x and ARM first. But I presume, it doesn’t work, neither. Then I will start debugging…

Floo writes

The problem was the call of std::shared_ptr pointers accross boundaries between libupnpp and the main programm. Due to different dependencies used for compiling the autotools-project for the library and Qt-project of upplay different and incopatible versions of libstdc++ were used for the std::shared_ptr template. To solve the problem I converted the libupnpp to a Qt project to ensure compiling all parts with same dependencies.

medoc92 writes

Wow, this must have been beastly to debug… Having multiple versions of the libstdc++ development packages on the same system does seem like a recipe for failure though. Just out of curiosity, is there a reason why you can’t keep only one ?

Floo writes

I have no idea so far! But I discuss this topic here: http://stackoverflow.com/questions/31804158/shared-pointer-on-x86-and-arm/