-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
emscripten cross-compile wasm-ld: error: duplicate symbol _Py_LibHacl_Hacl_Hash_*
#133042
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
Comments
Mmh, EMScripten with shared dependencies is experimental so I should actually force static linking in this case. You will likely encounter the same issues with the other HACL* primitives as they would also have duplicated symbols. As you can see on your PR, the change is breaking for the regular builds. I'll see what I can do (probably a similar issue as we had with WASI). |
Thx for the quick reply! Yes, just removing the objects is just breaking the regular builds. However, this is the only part that fails my shared build. One part of the configure script also caught my eye: Lines 7960 to 7966 in 614d792
|
WASI requires static linking but I'm unsure whether emscripten can have the corresponding built-in modules. If needed, I can just.. disable the HACL* primitives. I can't test locally because I have a "python.mjs" not found and I don't know how to fix it. |
Question: would forcing |
OK I think I know the issue. At the final makefile step, we have something like that:
The first occurrences are of Hacl* files are coming from each individual modules, but the last ones are indeed coming from HMAC. It's not an issue for regular compilers but for emscripten it appears that it's an issue (though I don't know why??) I'll make it so that the configure script can figure out the duplicates. |
Ok it's much more complex than I thought. Question, can you check if the following would solve your issue: -if test "$ac_sys_system" = "WASI"; then
+if test "$ac_sys_system" = "WASI" -o "$ac_sys_system" = "Emscripten"; then I don't have time now to fix the build entirely (sorry) but I'll have a look again tomorrow. If this still fails, we should make it so that only unique |
I'm marking it as a release blocker because I'm leaving tomorrow and won't be back before the next beta release so we need to find a solution in the next 24 hours (otherwise it's annoying for those working with Emscripten). It's not a true release blocker though but it's to keep in mind that this must be addressed before releasing the next sources. |
Tagging @hoodmane for his input. |
Ok, static linking doesn't work either. It's really because the
For the next beta, let's just disable HACL* HMAC. It's a new feature already so it's fine if we don't support it yet for Emscripten. |
Bug report
Bug description:
For the emscripten build, during building of the python executable, all the
LIBHACL_*_LIB_SHARED
are used as linker flags, however theLIBHACL_HMAC_LIB_SHARED
flag contains objects that are already contained in otherLIBHACL_*_LIB_SHARED
flags. This happens, because LIBHACL_MD5_OBJS, LIBHACL_SHA1_OBJS, LIBHACL_SHA2_OBJS, LIBHACL_SHA3_OBJS and LIBHACL_BLAKE2_OBJS are all included inLIBHACL_HMAC_LIB_SHARED
throughLIBHACL_HMAC_OBJS
via the Makefile.pre.in file.The configure script then sets
LIBHACL_HMAC_LDFLAGS=LIBHACL_HMAC_LIB_${LIBHACL_LDEPS_LIBTYPE}
which for a shared emscripten build leads to duplicate dependencies in the final build command which leads to duplicate symbols.Since I don't know the purpose of the object file references in the
LIBHACL_HMAC_OBJS
, I do not feel comfortable just removing them, even though that change fixes the emscripten build.CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Linked PRs
LIBHACL_HMAC_*
#133043The text was updated successfully, but these errors were encountered: