Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflicts when static linking a library that uses mbedtls #1126

Closed
tobil4sk opened this issue Jul 8, 2024 · 2 comments · Fixed by #1133
Closed

Conflicts when static linking a library that uses mbedtls #1126

tobil4sk opened this issue Jul 8, 2024 · 2 comments · Fixed by #1133

Comments

@tobil4sk
Copy link
Member

tobil4sk commented Jul 8, 2024

In static builds of lime projects, lime's mbedtls conflicts with hxcpp's (more info at openfl/lime#1767). This will be a problem especially with the mbedtls 3 upgrade (#1113).

I'm not sure if this might be the same issue as #777, because that talks about including .lib files.

There are two possible solutions I can think of.

Solution 1: Hxcpp uses lime's mbedtls

  • hxcpp supports compiling against multiple versions of mbedtls with conditional compilation, we add HXCPP_LINK_NO_MBEDTLS. We would also need to add a flag to set the include path of mbedtls (e.g. HXCPP_MBEDTLS_INCLUDE_DIR). Maybe we'd also need to allow passing in a custom MBEDTLS_USER_CONFIG_FILE path?
  • This is similar to how hxcpp libz linking problems #313 was resolved.
  • This is the simpler solution, but I'm worried about if there will be any issues with hxcpp's mbedtls threading config potentially missing? It was added in e5003a3 and it seems important.

Solution 2: Lime uses hxcpp's mbedtls

  • Expose the flags and files required for building hxcpp's mbedtls (without SSL.cpp). Lime can then be built against hxcpp's mbedtls, but not link it in the lime static library. Then, depending on whether hxcpp is built with ssl or not (hxcpp would have to provide some way to check this) *, lime has manually include hxcpp's mbedtls when finally linking the project.
  • This is more complicated but means that hxcpp uses its own version (with its threading config) and doesn't need to support multiple versions of mbedtls.

@hughsando I was wondering if you have any thoughts?

* EDIT: there is no need for this, as including the same sources twice doesn't seem to cause issues.

@tobil4sk
Copy link
Member Author

tobil4sk commented Jul 12, 2024

I'm working on using solution 2, and I've had some luck. In a hacky way, it's possible to link against mbedtls of current and old hxcpp versions just by using hxcpp_ssl. The flags haven't changed too much since it was introduced, so it should be backwards compatible as well. This includes SSL.cpp which is unwanted, but it's a minor inconvenience and can be solved for future versions by rearranging the hxcpp xml files as suggested (see #1133).

One issue I ran into was that MBEDTLS_NET_C has been undefined in the mbedtls config since e5003a3. This causes linking issues with the current version of cURL that lime is using (because it uses functions from net_sockets.c). Luckily updating cURL avoids this issue, but it would be best to remove this #undef from the hxcpp config to make it more universal: #1128.

@tobil4sk
Copy link
Member Author

As mentioned in #1133:

An external static library built with hxcpp that wants to link with mbedtls can now use:

  • <include name="${HXCPP}/project/thirdparty/mbedtls-flags.xml" /> to include the necessary compilation flags for compiling a source files that want to include mbedtls headers (i.e. include paths and defines)
  • <include name="${HXCPP}/project/thirdparty/mbedtls-files.xml" /> so that <files id="mbedtls" /> can be added to a target to link mbedtls.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant