Latest Posts

Topic: Linker Problems in Debug Mode

Arty
Avatar
Topic Opener
Joined: 2018-08-03, 12:14
Posts: 20
Ranking
Pry about Widelands
Posted at: 2018-11-05, 22:38

I am working on Windows 7 (64 bit) and use msys64 to build widelands. This works fine for release builds, but I have trouble to finish any debug builds. Everything works fine except linking most of the executables. If I use cmake and ninja as usual then I'll three ld.exe processes, all accumulating memory. A minute or so later each of them hogs 2 - 2.5 GB (depeding on what else I have running), then Windows starts compaining that the processes use too much memory (I "only" have 8 GB total), then the processes start to use a little bit less (does WIndows force them?), and a couple of seconds later the linking fails:

[1/4] Linking CXX executable src\widelands.exe
FAILED: src/widelands.exe
cmd.exe /C "cd . && C:\msys64\mingw64\bin\g++.exe -g  -mwindows @CMakeFiles\widelands.rsp  -o src\widelands.exe -Wl,--major-image-version,0,--minor-image-version,0  && cd ."
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/ui_fsmenu/libui_fsmenu_network.a(netsetup_lan.cc.obj): could not read symbols: memory exhausted
collect2.exe: error: ld returned 1 exit status
[2/4] Linking CXX executable src\economy\test\test_economy.exe
FAILED: src/economy/test/test_economy.exe
cmd.exe /C "cd . && C:\msys64\mingw64\bin\g++.exe -g   @CMakeFiles\test_economy.rsp  -o src\economy\test\test_economy.exe -Wl,--major-image-version,0,--minor-image-version,0  && cd ."
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/wui/libwui.a(attack_box.cc.obj): could not read symbols: memory exhausted
collect2.exe: error: ld returned 1 exit status
[3/4] Linking CXX executable src\io\filesystem\test\test_io_filesystem.exe
FAILED: src/io/filesystem/test/test_io_filesystem.exe
cmd.exe /C "cd . && C:\msys64\mingw64\bin\g++.exe -g   @CMakeFiles\test_io_filesystem.rsp  -o src\io\filesystem\test\test_io_filesystem.exe -Wl,--major-image-version,0,--minor-image-version,0  && cd ."

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: out of memory allocating 184216 bytes
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

First question: Why are the three linking steps even done at the same time? And can we prevent that via cmake files?

Linking them manually one by one seems to work. Or at least linking widelands.exe worked, I didn't try the others. Then it was only one ld.exe process which stayed relatively stable at about 2.5 GB memory usage, and after a couple of minutes the linking successfully finished.

Is it normal that the linker requires that much memory for widelands? Is it normal that the debug version of widelands.exe is 680 MB in size?

Maybe this is all normal and I am just not used to big projects, but this seems a bit excessive to me. And if this is not normal: Has anyone else had those issues? Any ideas how to overcome them?


Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 327
Ranking
Tribe Member
Posted at: 2018-11-05, 22:53

It seems your simply running out of memory. Three jobs are executed because you have a quadcore-cpu.

It's 3 jobs because of this addition in line 202 in the compile.sh script.

$buildtool -j "$(nproc --ignore=1)"

From what I can tell, this size (680 MB) seems to be right, for the debug version.


Top Quote
einstein13
Avatar
Joined: 2013-07-29, 00:01
Posts: 1118
Ranking
One Elder of Players
Location: Poland
Posted at: 2018-11-05, 22:54

I remember that before AppVeyor age, Tino provided debug builds on demand and the exe file was about 130 MB. So your 680 MB is a bit too much. EDIT: maybe something changes in last 2 years? I may be wrong here.

Are you demanding windows builds? If you are changing Widelands code by yourself, probably that is the only way, but if you want to have just up-to-date version, you can try AppVeyor:
https://ci.appveyor.com/project/widelands-dev/widelands

And if you have to build something (f.e. branch), you can also try building under Linux. If I have to build, I use virtual machine (VmWare) of Ubuntu, where compiling Widelands takes some time, but has no errors and with my poor knowledege about C++, Widelands code and Linux commands is still possible to reach face-wink.png .

Edited: 2018-11-05, 22:55

einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top Quote
stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 327
Ranking
Tribe Member
Posted at: 2018-11-05, 22:56

Tinos build did not contain any music files.


Top Quote
Arty
Avatar
Topic Opener
Joined: 2018-08-03, 12:14
Posts: 20
Ranking
Pry about Widelands
Posted at: 2018-11-05, 23:10

Thanks for the quick answers.

Yes, I was actually aware that it tried three processes at once due to multiple cores, I basically was just wondering why this is the default if linking is such a memory hogger. (I mean, I am aware that my 8 GB memory isn't exactly a lot nowadays, I just had assumed that it should be more than sufficient for linking.) But good to know, where I can change this in the compile script. Thanks.

I have started contributing to Widelands as developer, so I am building on my own machine. I usually don't even make debug builds if I can avoid it, but occasionally it might be necessary, so it's good to know how to do this easily despite having lowish memory available.

As for Linux....I must admit that I haven't used Linux in 15+ years and have become somewhat complacent with Windows. Maybe I'll set up Linux again.


Top Quote
Tino

Joined: 2009-02-20, 17:05
Posts: 252
Ranking
Tribe Member
Location: Somewhere in Germany...
Posted at: 2018-11-06, 07:37

stonerl wrote:

Tinos build did not contain any music files.

He is talking about the exe file size, not the installer file size.

Arty: You are completely fine, i think my debug exe's were 600-800MB. I just stripped them before including them. Yes, i stripped both debug and release builds...

And i think also, that our build/link process is atm a total mess due to circular(?) dependencies. I ran into the same problems on Appveyor (only 3,75GB RAM), so there i reduced the memory usage by (see appveyor.yml):

-DOPTION_BUILD_WEBSITE_TOOLS=OFF -DOPTION_ASAN=OFF -DCMAKE_JOB_POOLS=\"linking=1\" -DCMAKE_JOB_POOL_LINK=linking

So this does not build the website tools (one linking job less), turns off the ASAN check, defines a job pool with the size of 1 and use it only for linking. So compiling still does use every core available, but linking is not parallelized. I am using ninja, but cmake should map this fine to options for make, too. Also you can disable building the tests, reducing the time for building by half. Our debug builds build in ~1 hour an Appveyor, release builds in ~30 minutes. The additional 30 minutes are only linking time for all the executables...

Edited: 2018-11-06, 07:41

Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2018-11-06, 19:51

I have been trying to attack those circular dependencies, but it's a huge and convoluted task. So, I have only made a small dent in it and it will take a couple of years at the rate that I'm going. For some reason debug builds under Windows are about twice the size of debug builds under Linux face-sad.png


Busy indexing nil values

Top Quote
stdh
Avatar
Joined: 2013-08-04, 22:05
Posts: 41
Ranking
Pry about Widelands
Posted at: 2018-11-19, 21:07

Those CMake options Tino gave are quite interesting, with them I can compile Widelands without swapping. Maybe those of us with a modest amount of RAM would appreciate it if they were set as defaults? I don't know if parallel linking gains much time on a non-modest computer - can someone confirm or deny this?


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2018-11-20, 09:04

We have added a "-j" option to the compile script, so you can tell the compiler to use only 1 thread there. You could also compile with the default setting, abort it when it starts linking the big libraries and call it again with -j 1 for the linking.


Busy indexing nil values

Top Quote