Select to view content in your preferred language

cmake/cpack shared libraries

1456
4
05-16-2022 02:56 PM
FlipVernooij
Emerging Contributor

I have finished my QT/ArcGIS application and I want to start share it with my users.
Yet I don't get how to do this correctly.
I want to release packages for linux, osx and windows, but settled to getting a linux version released first.

My users haven't got the arcGIS api installed, nor will the ever want to, so I need to ship the API within my package same will most probably be the case for QT.

Now I see that you provide a libEsriRuntimeQt.a with your api, yet after compilling only the .so's are included . Is it possible to replace both the .so files with the single static .a library (and if so, how?)

How do you deal with this normally, I am for sure not the first with this issue yet there is next to nothing to find about this on the internet. How do you provide the shared libs from QT with you application for instance, are you requiring your users to manually download and install QT before they can install your program?

Sorry for the absolute rookie questions but this is the first time I need to build a package with shared objects.

0 Kudos
4 Replies
LucasDanzinger
Esri Frequent Contributor

The static libraries will be compiled into your application, and the libEsriCommonQt.so and libruntimecore.so shared libraries need to be in your application's path. The easiest way to do this is to place the shared libraries that your app depends on next to the executable. I'd recommend referencing the sample applications we have as a starting point. You can inspect the libraries there and replicate the structure/required libs in your app:

 

https://www.arcgis.com/home/search.html?t=content&q=tags%3A%22CppSampleViewer%22 

FlipVernooij
Emerging Contributor

Thanks for your reply, I have been pretty busy on this topic.
As you say, when compiling and running the application straight from within CLion having both .so files next to my compiled binary does the trick. I simply do this by adding: 

add_custom_command(TARGET ${STK_CURRENT_TARGET} POST_BUILD
COMMAND cp ${STK_ARCGIS_LIB_DIR}/* $<TARGET_FILE_DIR:${STK_CURRENT_TARGET}>)

 to my CMakeLists.txt (be aware that you need to set all the ${STK_*} variables yourself

Now my problem is that when I build my mac .app package, cpack somehow can't find those .so files.
Running my bundle  target, at the moment cpack starts its magic, this is its output:

Consolidate compiler generated dependencies of targetmyApplicationTarget
[100%] Built target myApplicationTarget
[100%] Running CPACK. Please wait...
CPack: Create package using External
CPack: Install projects
CPack: - Install project: myApplicationTarget []
CPack: Create package
ERROR: no file at "/usr/lib/libEsriCommonQt.dylib"

Notice the last line, it tries to load the ?first? .so file from /usr/lib
How can I set the proper include path for cpack in order to fix this?

ps. changing "POST_BUILD" to "PRE_BUILD" unfortunately doesn't seem to work either


0 Kudos
FlipVernooij
Emerging Contributor

Just an update, it seems that libruntimecore.dylib is correctly placed in the frameworks directory and is being linked correctly. libEsriCommonQt.dylib however is not and even placing it in the Frameworks directory doesn't fix the problem (placing it in /usr/lib does btw.)

Why is only the first file linked and not the second, can the compiler not find the dependency and if so how can I add the dependency manually.

tnx 😛

0 Kudos
LucasDanzinger
Esri Frequent Contributor

Hello,

 

Sounds like you were able to get Linux and Windows working?

 

For Mac, it gets a little bit trickier. Have you run the macdeployqt script (described here https://doc.qt.io/qt-5/macos-deployment.html)? Generally to build our sample viewers for mac, our workflow is: build the app, run macdeployqt script, copy in the remaining dylibs (EsriCommonQt, runtimecore), and run `install_name_tool -change` on them/the app executable so the exe looks in the app bundle for the libs and not elsewhere. This step is necessary because the dylibs contain references to the library dependencies with specific paths - you can double check the references with `otool -L`. Hopefully this gets you on the right track

0 Kudos