Error LNK1181 when USE_SHARED_MBEDTLS_LIBRARY CMake / MSVC #1130
Labels
bug
component-platform
Portability layer and build scripts
help-wanted
This issue is not being actively worked on, but PRs welcome.
Comments
|
Hi @solvingj Thank you for reporting this issue! |
|
Note that this is reproduced only when building a shared library. |
|
ARM Internal Ref: IOTSSL-1805 |
|
Hi @RonEld indeed it's a problem specific to building for shared. Also, I'm not sure how building it in the root would be relevant but I tried it anyway and got the same error. I chatted with a C++ library expert from microsoft about it after opening this ticket. He tried to help fix the building of shared library, and ultimately indicated that building mbedTLS shared with MSVC is simply not possible the way it is currently set up. Here were some excerpts comments:
|
|
Hi @solvingj Thanks for your input
When doing the following from the Mbed TLS root directory( Don't forget to delete the I managed to make it successfully build. Please confirm. As for the error itself, although it is a link error, I believe it should be related to the build of I think it is related to the line: and it is probably because the linker can't find |
|
No, it doesn't work if i build from the clean project root. I get the same error as before. It's still unclear to me why you think that would make any difference, especially since it's bad practice to build in source like that. Perhaps if you start from a clean source you'll reproduce the error. Here is my complete log: |
4 tasks
|
@RonEld the bad news is that doesn't fix the problem. The good news is that I got lucky through trial and error and made some progress. I can get the build to succeed if I just run it twice in a row. This indicates that the file |
|
Of note, the PR you submitted is irrelevant to this issue. |
|
Hi @solvingj Thanks for your information. |
|
I can confirm that this is an issue in mbedtls 2.13.0, using the VS2017 cmake generated projects. It fails only on the first build attempt after project generation. Reattempting the build succeeds. Interestingly enough, the cmake generated NMake projects seem to succeed without issue. |
RonEld
added
tracking
archived
|
Occurs the same issue, (mbedtls 2.16.5) I found must build shared library by specific order, so must build static libraries first and then build shared libraries: # must enable `USE_SHARED_MBEDTLS_LIBRARY` and `USE_STATIC_MBEDTLS_LIBRARY` at the same time
cmake . -D USE_STATIC_MBEDTLS_LIBRARY=ON -D USE_SHARED_MBEDTLS_LIBRARY=ON
cmake --build . -t mbedcrypto # generate mbedcrypto.dll
cmake --build . -t mbedcrypto_static # generate mbedcrypto.lib
cmake --build . -t mbedx509 # generate mbedx509.dll (depends mbedcrypto.lib)
cmake --build . -t mbedx509_static # generate mbedx509.lib
cmake --build . -t mbedtls # generate mbedtls.dll (depends mbedx509.lib)
cmake --build . -t mbedtls_static # generate mbedtls.libMy environment:
|
|
it can success but dll donot have export table.. |
|
This is still broken in 3.2.1 -- it only links by accident, since the static libraries and shared libraries both have the same name (so instead of linking shared to shared, it links shared to static). That also explains why it sometimes "works" on the second attempt (there is no dependency chain defined between the static and shared -- understandingly -- so the lib files don't necessarily get built in time). It becomes really evident when you explicitly disable static libs and only try to build shared -- in that case it never succeeds. |
|
I'm reopening this issue since the problem is still present. Note that this issue is solely about building the shared libraries. A DLL export table is a different topic and out of scope here. If you know how to fix this, please submit a fix, and, preferably, add something to the CI scripts that would catch the problem. If this can be reproduced with MingW, the preferred way to test is in |
gilles-peskine-arm
removed
the
archived
|
@gilles-peskine-arm I'll see if I can look at it when I have time. Right now I just need a dependency for another dependency that can build on windows (and all that to be able to do some time-critical work), and static will work OK for now. Just wanted to mention my observations. I have a feeling, tho, that without exports there's not really a way to make this behave as it (IMHO) should. |
|
We're still hit by this bug w/ 3.4.0 on msvc. There's no such bug if one cross compiles with mingw on linux. It's hard to believe that such a bug has been around for such a long time. Unfortunately I have no clear idea on a fix. |
|
3.5.1 still has this problem, unable to generate the import library lib required for the dll in windows. |
facebook-github-bot
pushed a commit
to facebookresearch/ocean
that referenced
this issue
May 23, 2024
Summary: Issue Mbed-TLS/mbedtls#1130 was opened in 2017. The last comment on the issue from 11/2023 reports "still a problem". Defining CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS will export function symbols to a DLL, but there are some .c and .h changes necessary to export global variables. See https://cmake.org/cmake/help/latest/prop_tgt/WINDOWS_EXPORT_ALL_SYMBOLS.html. Also, we upgrade from mbedtls 3.5.2 to 3.6.0. Reviewed By: enpe Differential Revision: D57745357 fbshipit-source-id: ab5e5c357fddd7df41259d9282a5d3cb653fea8d
thomas43
pushed a commit
to aja-video/mbedtls
that referenced
this issue
Jun 7, 2024
…ding DLL's(shared) on windows
thomas43
pushed a commit
to aja-video/mbedtls
that referenced
this issue
Jun 7, 2024
thomas43
pushed a commit
to aja-video/mbedtls
that referenced
this issue
Jun 8, 2024
thomas43
pushed a commit
to aja-video/mbedtls
that referenced
this issue
Jun 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Bug
OS
windows
mbed TLS build:
Version: 2.6.0 and 2.1.9
OS version: Windows 10
Visual studio version: 2017
Expected behavior
Should be able to build shared library.
Actual behavior
Steps to reproduce
Git clone or extract the latest release of this library. From the project root, do the following.
The text was updated successfully, but these errors were encountered: