QML/C++ application with dynamic link libraries



  • My app uses quite a lot of my C++ code library. HoweverI do not intend to share all this code. Therefore most of the code has been compiled as a dynamic link library. The main source for handling and especially handling qml and all the gui stuff is still in the main source and shall stay there.

    I have managed to create dynamic libs with subdirs template. The compilation of the components is working and also the linking with the libraries which needs a work-around because of a creator bug.

    The apk archive is generated and also deployed to the device and started. Unfortunately there is a crash because some of the quick controls are missing (possibly only the start of a list anyway). I have checked the content of the apk archive and clearly there are qml components missing which have not been included.

    I have created in the mean time an isolated project with only the app and linking to the dynamic libraries. This is did not change a thing. The build apk has an issue and does not include all required qml modules.

    Any suggestions?



  • @koahnig You don't need to organize your code into DLLs. There is no requirement to share your code unless you modify the Qt sources.



  • @Tom_H

    Thanks for your reply.

    Unfortunately I have to share some of my code, but some parts shall be hidden in dlls. Only the header files will be given to the customer.

    At the moment I am getting an error message that main library cannot be found. The name given is the only java module. That is really odd.


  • Moderators

    @koahnig I guess the issue is with androiddeployqt it's probably only parsing your main application and grading all related includes that way.

    You may be able to call it manually and add that way the missing dependencies of your library but I wouldn't even know where to look for the documentation on that tool.

    Maybe you could include a dummy class/file that requires all dependencies/includes that your libraries use and trick it that way?



  • Hi,

    I've solved similar issue by adding the following to *.pro file:

    TEMPLATE = app
    #........
    android {
      ##....
      ANDROID_EXTRA_LIBS += $$OUT_PWD/libs/myLib1/libMyLib1.so\
                            $$OUT_PWD/libs/myLib2/libMyLib2.so\
       ##...etc
       ## then (if necessary)
        INCLUDEPATH = INCLUDEPATH += libs/myLib1 libs/myLib2
    
       ## and for proper linking:
        LIBS += -Llibs/myLib1/ -lmyLib1 \
            -Llibs/myLib2/ -lmyLib2 \
    }
    #......
    

    This is strongly related to my sources tree layout, so inside directory with this pro file (TEMPLATE = app) there is:
    libs/myLib1
    libs/MyLib2
    with TEMPLATE = lib apparently.
    And above everything there is TEMPLATE = subdirs pro file to handle all of that.
    You will need to adjust that example to yours.



  • Thanks guys for reading the post and trying to help.

    Ultimately the problem was as very often between keyboard and chair. Other incredients were the most confusing error messages of the Android sdk compiler and linker. A part played also a creator bug for setting additional libraries used for building apk archive.

    @J.Hilk you could be right with androiddeployqt and also the advice of @SeeLook might helped. However, around that time I made yesterday my final attempt which succeeded and I called it a day.

    I think it is not conclusive, but may be the origin of my problems.
    The main project folder was initially holding the pro file and everythink was already in subfolders. This is also true for the main sources and java stuff including AndroidManifest.xml. Now by changing to a subdirs project for the building. I replaced the pro in main folder with a subdirs pro file. This requires an additional subfolder for the new pro file due to the subdirs template mechanics. I had added the subfolder and redirected from there to pull the required files and setting the pathes to the other subfolder where the stuff was. I am pretty sure that the pathes were all correct, but apparently not a good idea for the use of one of the tools involved.
    After correcting and having a straight increasing cascade of subfolders I managed to have sufficient cinfusion created to keep me busy.

    My conclusion is to keep the project setup straight and avoid parallel back-stepping in your overall subfolder structure.
    The output of Android SDK compiler, linker and also at run-time were pointing into different directions and always away from where the problem was.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.