Skip to content

Conversation

ze2j
Copy link

@ze2j ze2j commented Mar 6, 2025

Fix 1729

Tested on Linux only.

Note: I didn't manage to remove the ar command print in non verbose builds.
output

To reproduce/test:

  • make sure the/path/to/godot-cpp is long enough (at least 47 characters)
  • use this extension_api.json
  • build godot-cpp as usual on a linux system

@ze2j ze2j requested a review from a team as a code owner March 6, 2025 12:41

def _build_static_lib_with_rsp(target, source, env):
target_lib = str(target[0])
rsp_fd, rsp_path = tempfile.mkstemp(suffix=".rsp")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason you aren't using with TemporaryFile(suffix=".rsp") as rsp_file? Using that would allow you to skip the finally step of clean up because it cleans up after itself.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a left over of a bad example I copy pasted during my experimentations. Will fix, nice catch!

@enetheru
Copy link
Collaborator

enetheru commented Mar 6, 2025

aww linux only, i was hoping to test it for msys and mingw on windows see if it helps mingw link times at all(unlikely)

@dsnopek
Copy link
Collaborator

dsnopek commented Mar 6, 2025

Thanks for starting on a PR for this!

This should work on MSYS with mingw, since I think it uses GNU binutils. And, I'm not sure this will work on Linux if using ar from LLVM. So, I suspect specifically targeting this to Linux isn't the right way to go, I think we probably want to check for ar from GNU binutils.

Have you tried building on other platforms? I suspect this is a problem on Windows and MacOS too, and, in fact, my guess would be that Windows has a smaller limit than Linux.

Ideally, any solution to this would address all platforms and tool chains - unless this isn't a problem on other platforms and tool chains

@enetheru
Copy link
Collaborator

enetheru commented Mar 6, 2025

I'm not sure this will work on Linux if using ar from LLVM.

https://llvm.org/docs/CommandGuide/llvm-ar.html

@<FILE>

    Read command-line options and commands from response file <FILE>.

@dsnopek
Copy link
Collaborator

dsnopek commented Mar 6, 2025

https://llvm.org/docs/CommandGuide/llvm-ar.html

@enetheru Oh, awesome, thanks for looking that up!

I guess this means it'll work when building for Android too, because I think the Android tool chain uses clang

@ze2j ze2j force-pushed the fix_shell_argument_limit branch from 13cf09a to 5458596 Compare March 7, 2025 12:23
@ze2j
Copy link
Author

ze2j commented Mar 7, 2025

I made the suggested fixes and included MinGW.

@dsnopek I’ve only ever built my project on Linux, so I’m not sure if this issue can be reproduced on other platforms. Windows seems to have an 8192 limit, so my guess is that there’s no issue.

I took a very pragmatic approach here, but if you prefer a more general one, I won’t be offended if you decide to close this PR. I won’t be able to spend time implementing a more general solution, but I can help test it on my project if someone comes up with one.

@enetheru
Copy link
Collaborator

enetheru commented Mar 8, 2025

I can't get the test integration compiling for mingw64 but everything else appears to work.

@ze2j
Copy link
Author

ze2j commented Mar 9, 2025

@enetheru Should I drop the mingw inclusion or there is still some hope to make it work?

@enetheru
Copy link
Collaborator

enetheru commented Mar 9, 2025

I'm not very experienced on the scons side, perhaps someone else can test? but if it's going to block merging I would drop it as it's not required to fix your issue yeah?

@enetheru enetheru added the topic:buildsystem Related to the buildsystem or CI setup label Mar 10, 2025
@dsnopek
Copy link
Collaborator

dsnopek commented Mar 14, 2025

I’ve only ever built my project on Linux, so I’m not sure if this issue can be reproduced on other platforms. Windows seems to have an 8192 limit, so my guess is that there’s no issue.
[...]
Should I drop the mingw inclusion or there is still some hope to make it work?

I need to find some time to test this on a few platforms, and see if it's a problem elsewhere or just on Linux. If it's a problem elsewhere and this fix will work, I'd like to enable it everywhere that we can. If anyone else has time to test, that would be appreciated :-)

@ze2j: Is there any chance you could share the extension_api.json that you're using? Then folks will be able to easily reproduce the issue, without having to first make their own extension_api.json that will exhibit the problem

@ze2j
Copy link
Author

ze2j commented Mar 18, 2025

@dsnopek sure, here it is. Don't forget to use a path to godot-cpp long enough.

@comfyjase
Copy link

Hey, hope it's okay for me to comment on this!

Just wanted to mention I ran into the same issue in one of my own projects (see here) where the argument list was too long:
scons: *** [/home/runner/work/godot-project-template/godot-project-template/engine/godot-cpp/bin/libgodot-cpp.linux.template_debug.dev.x86_64.a] sh: Argument list too long

From what I can see in my own project it only appeared to be an issue when compiling on a Linux OS, the other platforms that built on Mac or Windows passed (see here).

I've tried these changes in my own godot-cpp fork and I have changed it slightly so that instead of using:
env["platform"] == "linux" it uses platform.system().lower() == "linux" and that takes into account compiling on Linux but for other env["platform"] targets. In my godot-cpp fork, everything passed with these changes apart from 🏁 Windows (x86_64, MinGW) (see here lots of undefined references) and I'm not sure why it's failing:
c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src\example.o:example.cpp:(.text+0x336): undefined reference to godot::String::String(char const*)'
I don't use MinGW myself so I don't understand what's going wrong with that part of the CI run.

These are my godot-cpp tool scripts in case anyone wanted to try them:
godotcpp.py
common_compiler_flags.py

And these are the diffs to highlight what the changes are:
common_compiler_flags.py
image

godotcpp.py
image
image

With these godot-cpp changes my project CI passes (see here) but as mentioned before the godot-cpp CI is failing for 🏁 Windows (x86_64, MinGW) so I'm not sure what the fix for that is.

Any ideas why the godot-cpp MinGW CI is failing with these changes?

@h4ilst0rm
Copy link

h4ilst0rm commented Oct 7, 2025

This issue happens / can be reproduced in MSYS2 mingw-w64-ucrt-x86_64-toolchain simply by cloning / cheking out godot-4.5-stable. Both MSYS and godot-cpp are in the root of a drive i.e. E:/msys64/... and E:/godot-cpp/... so there is no way to make the paths shorter.
This PR seems to fix it at least for scons platform=windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

topic:buildsystem Related to the buildsystem or CI setup

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cannot build my GDExtension with Godot 4.4

6 participants