-
Notifications
You must be signed in to change notification settings - Fork 252
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
Windows: Many symbols missing from built dll #2164
Comments
What was the cmake command that you used? |
I had @albinahlback would you accept a PR that adds |
Could you please answer Isuru's question?
Given that very few people use the developer version of FLINT on Windows, and we would have to touch basically every header, I find it hard to accept such a PR. |
We once had |
Sorry, I thought it was clear from my comment above that I mistakenly assumed it's a problem with the cmake file; but actually it turned out to be a limitation of meson.
I'm far from an expert on these matters but from reading mesonbuild/meson#2132 I got the impression that it is generally considered a good practice to explicitly define the public interface of the library via these dll export statements. And it seems to be the only supported way to build as a shared library using meson at the moment. |
You don't need FLINT_DLL everywhere since flint is a C library. You just need a list of symbols to generate a .def and pass it to the linker |
Closing as it is not a problem from any of the supported building systems. |
Thanks for the suggestion. Cmake's WINDOWS_EXPORT_ALL_SYMBOLS works like this, right? It generates a |
(The basic approach used by CMake, and also the basic approach used by other projects that support this, is to run a simple dumping script on all the *.o files enumerating symbols, and print that out as a .def file which is then used for the link stage itself. It's not that complicated to do, but none of the affected users who wanted this have yet found time to implement this and submit it as a PR to meson. And as a Linux user, I regard myself as the wrong person to drive this meson feature request. 😢)
Explicitly defining the public interface allows you to avoid some pain if you exported some symbols you didn't mean to and suddenly it's your stable ABI and you cannot get rid of it. It also allows you to have smaller shared libraries, do more link-time optimization, etc. Not everyone cares about this. It's a tradeoff, and micro-managing your public interface is not pain-free even without considering cross-platform support. |
After successfully building flint, I get a lot of "unresolved external symbol" errors when linking against it. An example is below.
And in fact,
flint.dll
only seems to expert a handful of symbols:These have
FLINT_DLL
in their declaration, the other don't. What do I miss?The text was updated successfully, but these errors were encountered: