-
Notifications
You must be signed in to change notification settings - Fork 128
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
2.10.0-RC1: Windows libffi linker issue #4019
Comments
Will try |
We probably need to see more of the CMake output, particularly the FFS part. It doesn't try to use FFI unless it finds it, but clearly it hasn't really found it. |
@eisenhauer , can you see the linked log file? I downloaded it from CI for full CMake details. |
Sorry, missed that... Looking now. |
I disabled libFFI, but there are other linker issues with FFS left:
|
Odd. From the looks of it things are going wrong with the MSVC linker import, but this stuff works fine in ADIOS CI with MSVC 19. I don't have a great first guess at the moment, but I'm wondering if the problem with FFI might be related. We're probably going to have to go through and compare the ADIOS CI logs for MSVC to see where things might have gone differently. Actually, I can't look at the moment, but one possible thing. I suspect that we're not disabling DLLs in MSVC CI. Do you need a static build? (That might explain both things. If the FFI module contained only a dynamic library, the static version might not be found, and things might be going wrong on the linker end with ADIOS as it's being used.) |
Yes, I need an all static build. |
When turning off libFFI, I get issues statically with building ADIOS2 of the form:
full log: adios2_link_ffs.txt |
It appears that the thirdparty packages we need for BP5 have not been setup to compile statically on Windows. The errors above I think are the result of having the declspec(dllimport) turn on those symbols unconditionally. (Those declspecs are leftover from a non-CMake build system, and while a lot of work was put in to make those libraries build and install statically and dynamically on non-windows systems, the windows work only included dynamic builds.). I've been doing some digging looking for a package that might do this the "right" way in CMake, but haven't had luck so far. I believe that one needs to employ the GENERATE_EXPORT_HEADER cmake command, but that's my only lead at this point. |
Yes, |
WINDOWS_EXPORT_ALL_SYMBOLS is done in the thirdparty libs, but it doesn't handle the declspec()s in the headers. I've tried just turning those off for the static build, but whatever the fix is, it seems to require more than that. |
|
Well, that's potentially good news. @vicentebolea Plausible? |
What convinced me of a CMake bug was that the target was not found even if a added a |
I responded to the wrong issue, this addresses the issue reported in #3903. Might still be worth checking if it's the same cause for this one. |
I believe that this was resolved with the 2.10.1 release. Please re-open if this is still an issue |
Describe the bug
I am still trying to compile ADIOS2 with C-Blosc2 on Windows in openPMD/openPMD-api#1554.
I now try to use ADIOS 2.10.0-rc1.
This does not link on windows with libffi issues.
To Reproduce
I am doing an all-static build.
See CI of openPMD/openPMD-api#1554, logs here:
adios2-2.10.0-rc1_libffi-link-issue.txt
cc @eisenhauer ?
The text was updated successfully, but these errors were encountered: