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

Building debug SwiftGodot on Windows throws linker errors (too many symbols) #589

Open
Dirk-Vantas opened this issue Oct 25, 2024 · 8 comments

Comments

@Dirk-Vantas
Copy link

Describe the bug
when building dynamic libraries on Windows 10 with the SwiftGodot project, it maxes out on symbols and trows a build error:
lld-link: error: too many exported symbols (got 66577, max 65535)

Versions
OS: Windows 10
SwiftGodot branch : 4.3
Swift : 5.10.1

Now I know that there has been work done on this issue ( #146 back in 2023 ) in bringing down symbol count below the hard limit of 65K that windows has. But it seems to have come back.

Now it could be that I am doing something wrong, or the newer version hasn't had the symbol count improved, but right now only a release build works.

@migueldeicaza
Copy link
Owner

Do you need a dynamic library?

If you use it as a static library, and then link your module with it, it should not hit that limit, could you confirm?

I am afraid a fuller fix is required, as discussed in #572

@Dirk-Vantas
Copy link
Author

So you mean compile a static version of the Swift Godot library and just use that as a dependency instead of listing the git repo inside the package file?

@Dirk-Vantas
Copy link
Author

@migueldeicaza in any case it fails both static and dynamic versions of my module in debug and only works when compiling for release.

But using release binaries throws the issue of Godot expecting PDB signatures while in development mode and providing release binaries trips the "unknown PDB format" error that I already reported on the slack server,
as the read signature is essentially nothing (0x0).

Would a workaround, for the time being, be to try and disable the reading of debug symbols by Godot or is there a way of compiling a release build with the necessary PDB information still contained in the library? As I can just continue working in Linux/MacOS and worry about the proper implementation once the stuff is resolved.

@migueldeicaza
Copy link
Owner

A quick workaround would be to disable types that you are not using, try this patch:

https://gist.github.com/migueldeicaza/96d1bf8b95247a73839e42dd43d88a75

@migueldeicaza
Copy link
Owner

The Godot folks told me that the approach they use for Godot C++ is to only generate static libraries, and they only expose the entry point in their extension. I would like to explore what is needed to do that for our extensions and share that guidance.

@migueldeicaza
Copy link
Owner

Mhm, I already default in main to Windows being a static library, would love if you could try building your extension that references this SwiftGodot static library directly and report if that works.

@Dirk-Vantas
Copy link
Author

Do you mean compiling the extension as a static with the .static option inside swiftPM? Or did you mean something else?

@Dirk-Vantas
Copy link
Author

A quick workaround would be to disable types that you are not using, try this patch:

https://gist.github.com/migueldeicaza/96d1bf8b95247a73839e42dd43d88a75

OK so I applied the patch to the main branch version as is (I didn't add anything to the exclusion list since I don't have the full list of what I am not using lmao), and now it compiles perfectly into a dynamic library in debug mode, Godot seems to be happy.

But now a funny side effect has taken effect:

Since I am referencing a modified local version of swiftgodot in my extension package file rather than the repository directly, it seems that swift is compiling swiftgodot and the extension dll into one and I no longer need to reference it in the gdextension file aswell.

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

No branches or pull requests

2 participants