search

eclipse-4diac / 4diac-forte

Eclipse Public License 2.0
31 stars 33 forks source link

Fix Mqtt and Mbedtls library link #96

Closed kumajaya closed 7 months ago

ernstblechaPT commented 7 months ago

@jwalt could you please take a look at this? I am almost sure that there will be problems on other platforms. Also: I am not sure if the solution for MQTT is a good one

kumajaya commented 7 months ago

@jwalt could you please take a look at this? I am almost sure that there will be problems on other platforms. Also: I am not sure if the solution for MQTT is a good one

Both commits will only affect win32.

jwalt commented 7 months ago

So with the 4diac-fbe, it will pose no problem. Our static libpaho would not hit this branch and we don't use mbedtls, so 4diac-fbe builds should continue working as before.

I am mildly uncomfortable with adding a special case based on the library name, but that part is already a bit messy and terribly system-dependent, so it's in line with existing practice. It should also not cause manual builds to fail, as far as I can see, so no serious objections from me apart from the general uncleanliness (which we already have in many places anyway).

ernstblechaPT commented 7 months ago

If I understand correctly the reason this is not a problem with 4diac-fbe is that libpaho is build with PAHO_WITH_SSL=ON which removes the dependency on crypt32?

kumajaya commented 7 months ago

Sorry, closed by accident.

kumajaya commented 7 months ago

If I understand correctly the reason this is not a problem with 4diac-fbe is that libpaho is build with PAHO_WITH_SSL=ON which removes the dependency on crypt32?

If I'm not mistaken, openssl on windows also requires crypt32. But I failed to use openssl to enable OPC UA security, so I switched to mbedtls.

jwalt commented 7 months ago

If I understand correctly the reason this is not a problem with 4diac-fbe is that libpaho is build with PAHO_WITH_SSL=ON which removes the dependency on crypt32?

No, the difference is that 4diac-fbe avoids the library-name hack that paho's build system tries to do. Our build uses the standard approach where static and shared libraries have the same name. Paho's hack is for when you want to make it easier for devleopers to link paho statically but not influence linking of any other libs you may be using. So this branch will not be hit when using 4diac-fbe.

4diac-fbe manages link time library dependencies externally by setting the proper CMake variables. Since it is a controlled environment and knows exactly what is needed, it does not need any heuristics in 4diac-forte's build system.

ernstblechaPT commented 7 months ago

4diac-fbe manages link time library dependencies externally by setting the proper CMake variables. Since it is a controlled environment and knows exactly what is needed, it does not need any heuristics in 4diac-forte's build system.

Thank you for your reply, I should have looked closer before guessing.

On the second look: 4diac-fbe pulls in the library dependency on crypt32 in https://github.com/eclipse-4diac/4diac-fbe/blob/release/dependencies/recipes/forte/build.cmake#L103 . As far as my tests go crypt32 is not needed for linking with open62541 but only with paho_mqtt. But I will need to do actual testing with 4diac-fbe to confirm this.

kumajaya commented 7 months ago

4diac-fbe manages link time library dependencies externally by setting the proper CMake variables. Since it is a controlled environment and knows exactly what is needed, it does not need any heuristics in 4diac-forte's build system.

Thank you for your reply, I should have looked closer before guessing.

On the second look: 4diac-fbe pulls in the library dependency on crypt32 in https://github.com/eclipse-4diac/4diac-fbe/blob/release/dependencies/recipes/forte/build.cmake#L103 . As far as my tests go crypt32 is not needed for linking with open62541 but only with paho_mqtt. But I will need to do actual testing with 4diac-fbe to confirm this.

As far as I know, the crypto backend that use the crypt32 library on Windows. A security enabled paho mqtt or open62541 always need crypt32.

ernstblechaPT commented 7 months ago

As far as I know, the crypto backend that use the crypt32 library on Windows. A security enabled paho mqtt or open62541 always need crypt32.

Thank you for the missing piece: I did not explicitly enable UA_ENCRYPTION on my build of open62541 - this is why i could get away without crypt32. Looks like I should make time to switch to 4diac-fbe rather sooner than later...