I'm assuming that collect2 is trying to run another program (perhaps ld.exe) but I can't figure out the specifics. Is there a way to track execution requests or get more verbose output?
I've had the problem occur under several different installations of MinGW. I suspect it's because I'm not installing under C:\MinGW but while the official MinGW says to install there the TDM install specifically says NOT to and offers C:\MinGW32 as the default. They wouldn't offer a default if it didn't work so what gives?
I'm using TDM installer stable 4.5.0 and as far as I can tell everything is where it is supposed to be.
Ah. Running collect2 with -debug has revealed the problem. It's unwrapping the @response file and passing the entire file list to ld.exe.
That completely defeats the purpose of using a response file in the first place (to get around the 32k limit on args).
I wonder if anybody in the Spring community has successfully built Spring on Win32/MinGW lately? I mean using the latest git source (as of last week), GCC 4.5.0+ and git mingwlibs. As far as I can tell linking spring.exe will exceed 32k characters and cause this error yet I seem to be the only person who is affected.
So it really doesn't matter where the build directory is located because what counts is the paths inside the Spring source tree.
There's a couple of paths to library files in the commandline but shortening them won't save enough characters. As it is right now the complete arguments weight in at 33491 characters and the most I can save by reducing the build root is less than 100 characters.
jK, I guarentee it won't make the slightest bit of difference.
If you want to try and prove me wrong be my guest. I may not be the worlds' greatest expert on building complex projects like Spring but I've spent a LOT of time on this particular bug and I know exactly what is happening. I knew the first time hoijoi mentioned it that it wasn't going to work.
I've already reported this to the mingw and TDM bug trackers as it's almost certainly an issue with the MinGW binary releases.
Even if shortening paths did help (it doesn't) it would still just be delaying the inevitable. Sooner or later we'd be using C:\ as our build directories because as Spring grows so do the number of objects (at least until somebody refactors the whole project).
But as I said the paths causing the issue are all relative to the spring build directory, not the drive root. The few absolute paths being passed amount to a total of no more than about 200 characters in total while the amount of characters over 32k is something like 1400.
good job on reporting this, but unfortunately i believe the only real fix for now will be to split spring into at least two libraries; any fix to the toolchain will find its way into release builds in at least 6 months.
There is another option, though I'm not looking forward to it.
With help from the GCC bug report I believe I've tracked the problem down to an issue in the configuration of the TDM and official builds. The linker supports response files and collect supports passing them but it only does so if the toolchain was configured using --with-gnu-ld or it autodetects this from the ld on the build system. In other words the feature is there but it must be explicitly enabled when GCC is built.
The solution then is to rebuild gcc with this option set. This will create a collect2.exe that passes its args in a new response file to ld.exe.
I can't imagine building a working MinGW GCC is going to be easy but I do have a working linux hosted mingw32 cross-compiler so it isn't out of the realm of possibility either.
I could just resume building spring cross-compiled. My original motive for building on windows was to have a working GDB.exe but I've since learned about gdbserver which solves this issue for cross builds.
On the other hand that basically means until spring is split up, or the upstream packages adopt the fix, or a workaround is found, spring can no longer be built on windows (unless the VS builds work, which I doubt). So I'm going to try my hand at building a 4.5.0/dwarf2 based mingw32 GCC and put it up on my mirror if successful. No promises though.
remove spring-headless, spring-dedicated, and spring-multithreaded from your build and you should have no problems building spring on windows (will greatly reduce the amount of arguments passed)
I've tried "make spring" in the past. It doesn't solve the problem.
The arguments in question are all objects (*.obj) being linked into spring.exe (though I believe spring-multithreaded is also affected).
To help people understand the issue better, I've attached the response file used by engine targets (which should be both spring and spring-multiheaded)
Attachments:
File comment: D:\SpringTest\debug\rts\builds\default\CMakeFiles\engine-default.dir\objects1.rsp objects1.rsp.txt [30.88 KiB]
Downloaded 23 times
I couldn't get MinGW to build after trying for a few hours so I gave up and went back to cross-compiling on linux. I'll just wait until there's an upstream fix. I don't even need this anymore because I learned how to use gdbserver and my linux box compiles ~12 times faster than my Windows box.
There are long-term plans to make spring more modular, which will reduce the number of C++ files built at once (you build libraries then link those). I wouldn't hold my breath for it though.
Seems like the best shortterm solution is to do what jK did and try to get a working collect2.exe from somewhere else. I'm surprised though that the 3.4.5 versions works with a newer GCC.
jK, can you upload your working collect2? I'm going to make one last attempt to build GCC using a cross-compiler but if that fails I'm not going to waste any more time on this and that will have to be our official workaround (or VS 2005 for those that use it).
I first tried a 4.4.0 one, but it failed too. So I tried the 3.4.5, which works and wonders me too, because the file is just 10% in size of the 4.5.0 one.
It seems that in response of the posted bug: https://sourceforge.net/tracker/?func=d ... tid=974439 The issue has been fixed in TDM mingw. So one fix now (besides using TDM, which I don't feel like now ), is to use collect2.exe from that package. I have tried that and it also works.
The old collect2 is still required for current official gcc, but otherwise, working fine here, no changes necessary (using the GUI download tool even!).
Users browsing this forum: No registered users and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Home
Download
Login
Register
FAQ
Search
), is to use collect2.exe from that package. I have tried that and it also works.