Cross compilation of paho.mqtt.cpp

[andreamanera]

Hello,
I am developing a project for which I need to cross compile the paho mqtt cpp library on build platform x86_64 to host platform aarch64, first of all I cross compiled the paho mqtt c library and I think that I was able to do it properly, I didn't received any error and checking the files were effectively compiled for ARM aarch64, but when it comes to build the cpp library trying different times I've faced different errors. Now I would like to know if someone was able to achieve my goal and if so if you can provide a guide on how to do it.
Thank you for the support

[andreamanera]

This is the error I get now (I forgot to specify that I am building on Ubuntu 18.0.4), I built the C library with PAHO_BUILD_STATIC = ON and it seemed to work, but then I am not able to build the cpp library (again with PAHO_BUILD_STATIC = ON) because of this error.

[andreamanera]

well, I would have liked to receive some help from the community but nobody answered :'( , anyway thanks to hard work and the support of my colleagues I was able to solve by myself, if you need help feel free to contact me

[Zelif]

This is due to this issue and PR:
#469
#471

The changes that have been done are yet to be accepted in the C library but to solve it you can just grab the branch from the PR to solve it.

[Blackessst]

well, I would have liked to receive some help from the community but nobody answered :'( , anyway thanks to hard work and the support of my colleagues I was able to solve by myself, if you need help feel free to contact me

I'm having the same issue. How did you get it to work?

[andreamanera]

I do not know at which step are you but basically what you have to do is to separately cross-compile the c library, and you should have no problems in this step (I have done it statically, but probably it may works also dinamically), with PAHO_WITH_SSL set to FALSE otherwise you will have to cross-compile also the OpenSSL library (but it can be challenging), then you will have to manually move (I suggest to create an archive) the files related with this library so the .a files (.so if you built dinamically) and the includes of the library (that are usualy located in /usr/lib and /usr/include) into the directory of your cross compiler (in my case /usr/aarch64-linux-gnu/lib and /usr/aarch64-linux-gnu/include) then if you correctly set the path of library and headers in your toolchain file with SET(CMAKE_FIND_ROOT_PATH ...) you should be able to cross compile also the cpp library.

[Zelif]

I do not know at which step are you but basically what you have to do is to separately cross-compile the c library, and you should have no problems in this step (I have done it statically, but probably it may works also dinamically), with PAHO_WITH_SSL set to FALSE otherwise you will have to cross-compile also the OpenSSL library (but it can be challenging), then you will have to manually move (I suggest to create an archive) the files related with this library so the .a files (.so if you built dinamically) and the includes of the library (that are usualy located in /usr/lib and /usr/include) into the directory of your cross compiler (in my case /usr/aarch64-linux-gnu/lib and /usr/aarch64-linux-gnu/include) then if you correctly set the path of library and headers in your toolchain file with SET(CMAKE_FIND_ROOT_PATH ...) you should be able to cross compile also the cpp library.

For the Open SSL build I was targeting an older OS(bullseye armhf) which openSSL and crypto were included via
apt install libssl-dev but the issue is its an old build so the cmake does not find it as it is not under the library name of OpenSSL::OpenSSL. (older packages were just ssl and crpto)

Just in c library I had changed:

TARGET_LINK_LIBRARIES(${TARGET}
		PUBLIC
			OpenSSL::SSL OpenSSL::Crypto ${LIBS_SYSTEM})

TO

IF(__arm__)
	TARGET_LINK_LIBRARIES(${TARGET}
		PUBLIC
			ssl crypto ${LIBS_SYSTEM})
ELSE()
	TARGET_LINK_LIBRARIES(${TARGET}
		PUBLIC
			OpenSSL::SSL OpenSSL::Crypto ${LIBS_SYSTEM})

Otherwise I would have to do what you suggest and compile OpenSSL on the device first. @Blackessst if you are having the same issue as @andreamanera then just pull down the repo from the pull request and use that. I forked this lib mid December so I wouldn't have to worry about tracking this issue and suggest you do the same and check back every now and then hope that the guys doing the C library are able to review and put through the needed changes :D

[hmb]

As for release 1.3.2 I helped myself with a small patch, effectively reverting or enhancing f90f306. I need a static mqtt.cpp linking to a static mqtt.c and this helped. I then disabled the shared build and turned on the static one with

-DPAHO_BUILD_STATIC=ON -DPAHO_BUILD_SHARED=OFF

Here's the patch:

diff -u '--exclude=.git' -r paho.mqtt.cpp.orig/cmake/FindPahoMqttC.cmake paho.mqtt.cpp/cmake/FindPahoMqttC.cmake
--- paho.mqtt.cpp.orig/cmake/FindPahoMqttC.cmake	2024-03-20 16:53:46.550371236 +0100
+++ paho.mqtt.cpp/cmake/FindPahoMqttC.cmake	2024-03-20 16:59:37.545928922 +0100
@@ -11,6 +11,8 @@
     if(PAHO_BUILD_STATIC)
         set(_PAHO_MQTT_C_LIB_NAME ${_PAHO_MQTT_C_LIB_NAME}-static)
     endif()
+elseif (NOT PAHO_BUILD_SHARED AND PAHO_BUILD_STATIC)
+    set(_PAHO_MQTT_C_LIB_NAME ${_PAHO_MQTT_C_LIB_NAME}-static)
 endif()
 
 if(PAHO_WITH_MQTT_C)

[fpagliughi]

Yes apologies. I started fixing a number of build issues last year, and thought it would be easier to push some fixes into the Paho C lib first. But those haven't landed yet, so I'm just going to proceed with a v1.4 release based on the existing C lib.

The fixes for this issue are in line with what @hmb mentioned. The solution currently up in master requires the C lib to be built with the same static/shared options as you want to build the C++ library. So shared links to shared; static links to static. A build configuration error occurs if they are not matched.

I worry that might me more complaints than it solves, but at least it would work consistently across platforms.

And having the auto/submodule build of the C lib working properly using the PAHO_WITH_MQTT_C option, should help a lot to fix all of this... especially the submodule build would pick up the same static/shared flags.

[fpagliughi]

I'm hoping this is fixed with the new code for the v1.4 release. If not, feel free to re-open this ticket.