MinGW build failure

[pmconrad]

Build Error Description
Current develop branch fails to build with MinGW.
Note: examples below were on gitian build, but was reported originally by @crypto-ape for Linux and Windows, see #1706 (comment)

Build Environment

• Host OS: Ubuntu 18.04 LTS (as used by https://github.com/bitshares/bitshares-gitian/ )
• Host Physical RAM 16 GB
• Source Branch/Tag: develop (991bd75)
• OpenSSL Version: 1.1.1c
• Boost Version: 1.69.0
• C++ Compiler: gcc- (mingw)

Steps To Reproduce
Steps to reproduce the behavior (example outlined below):

1. Prepare https://github.com/bitshares/bitshares-gitian/ environment
2. run-gitian -b -O win develop
3. Enter container, then cd build/bitshares/build; make cli_wallet

Console Logs (optional)

/usr/bin/x86_64-w64-mingw32-as: CMakeFiles/graphene_wallet.dir/wallet.cpp.obj: section .xdata$_ZN2fc11generic_api12call_genericIN8graphene8protocol15public_key_typeENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEJSA_EEET_RKSt8functionIFSB_T0_DpT1_EEN9__gnu_cxx17__normal_iteratorIPKNS_7variantESt6vectorISM_SaISM_EEEESS_j: string table overflow at offset 10000206
/tmp/ccpQ5ari.s: Assembler messages:
/tmp/ccpQ5ari.s: Fatal error: can't close CMakeFiles/graphene_wallet.dir/wallet.cpp.obj: File too big

CORE TEAM TASK LIST

• Evaluate Build Error
• Provide build guidance
• Create Bug Report

[jmjatlanta]

https://digitalkarabela.com/mingw-w64-how-to-fix-file-too-big-too-many-sections/

It is similar to the /bigobj flag for MSVC

[crypto-ape]

https://digitalkarabela.com/mingw-w64-how-to-fix-file-too-big-too-many-sections/

It is similar to the /bigobj flag for MSVC

It is similar and technically it is a related problem, but in this case the big-obj switch does not solve anything.

In most cases, big-obj and a high optimization level ( say O3 ) helps, but here it it is simply too much for MinGW.

We might also notice that MSVC does not have this problem, even though it generates object files in the same format. This is probably due to differences between MSVC and MinGW when it comes to what is being written to the string table. I guess MinGW is just more chatty.

I don't know how to come around this, the solution I see is the splitting wallet.cpp into multiple files.

[jmjatlanta]

Related #950, #1413, #1432

I am curious if anyone has input as to why the PIMPL idiom should be used here. I see an increase in complexity with no real benefit (how many applications link in wallet.cpp?). Am I missing something?

I'd say ditch PIMPL + cut the file into logical classes that implement some portion of the wallet API. Any opposed?

[pmconrad]

IMO PIMPL should be kept.
That doesn't mean everything has to go into one file of course.

[pmconrad]

Fixed by #2013