Can't build with MinGW (only boost 1.75.0)

[Tectu]

Since merging #14 I am unable to build using MinGW.

Environment:

• Windows 10 (64-bit)
• MinGW-w64 (GCC 10.3.0)
• Boost 1.76.0
• Target: malloy-example-server-session (with added -> std::variant<response<>> return type on router handlers)

It seems like @0x00002a is able to build according to #18 (comment)

Using make:

====================[ Build | malloy-example-server-session | Debug ]===========
C:\Users\joel\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\211.7442.42\bin\cmake\win\bin\cmake.exe --build C:\Users\joel\Documents\projects\malloy\cmake-build-debug --target malloy-example-server-session -- -j 9

...

[ 91%] Building CXX object lib/malloy/CMakeFiles/malloy-objs.dir/controller.cpp.obj
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/as.exe: CMakeFiles\malloy-objs.dir\server\routing\router.cpp.obj: section .rdata$_ZTVN5boost5beast12basic_streamINS_4asio2ip3tcpENS2_9execution12any_executorIJNS5_12context_as_tIRNS2_17execution_contextEEENS5_6detail8blocking7never_tILi0EEENS5_11prefer_onlyINSC_10possibly_tILi0EEEEENSF_INSB_16outstanding_work9tracked_tILi0EEEEENSF_INSJ_11untracked_tILi0EEEEENSF_INSB_12relationship6fork_tILi0EEEEENSF_INSQ_14continuation_tILi0EEEEEEEENS0_21unlimited_rate_policyEE3ops11transfer_opILb0ENS2_15const_buffers_1ENS2_6detail8write_opISZ_NS2_14mutable_bufferEPKS15_NS13_14transfer_all_tENS2_3ssl6detail5io_opISZ_NS1A_8write_opINS0_19buffers_prefix_viewINS0_6detail11buffers_refINS1D_IRKNS0_14buffers_suffixINS0_16buffers_cat_viewIJNS1F_INS1H_IJNS2_12const_bufferES1I_S1I_NS0_4http12basic_fieldsISaIcEE6writer11field_rangeENS1J_10chunk_crlfEEEEEENS1J_6detail10chunk_sizeES1I_S1P_S1I_S1P_S1I_S1I_S1P_EEEEEEEEEEEEENS0_11flat_streamINS19_6streamISZ_EEE3ops8write_opINS1S_13write_some_opINS1S_8write_opINS1S_12write_msg_opINS1E_18bind_front_wrapperIMN6malloy6server4http10connectionINS2E_14connection_tlsEEEFvbNS_6system10error_codeEyEJSt10shared_ptrIS2G_EbEEENS0_10ssl_streamISZ_EELb0ENS1J_15basic_file_bodyINS0_10file_stdioEEES1M_EES2Q_NS1S_18serializer_is_doneELb0ES2T_S1M_EES2Q_Lb0ES2T_S1M_EEEEEEEEEE: string table overflow at offset 10000487
C:\Users\joel\AppData\Local\Temp\ccs8Ilkr.s: Assembler messages:
C:\Users\joel\AppData\Local\Temp\ccs8Ilkr.s: Fatal error: CMakeFiles\malloy-objs.dir\server\routing\router.cpp.obj: file too big
mingw32-make[3]: *** [lib\malloy\CMakeFiles\malloy-objs.dir\build.make:194: lib/malloy/CMakeFiles/malloy-objs.dir/server/routing/router.cpp.obj] Error 1
mingw32-make[2]: *** [CMakeFiles\Makefile2:749: lib/malloy/CMakeFiles/malloy-objs.dir/all] Error 2
mingw32-make[1]: *** [CMakeFiles\Makefile2:979: examples/server/session/CMakeFiles/malloy-example-server-session.dir/rule] Error 2
mingw32-make: *** [Makefile:240: malloy-example-server-session] Error 2

Using ninja:

====================[ Build | malloy-example-server-session | Debug ]===========
C:\Users\joel\AppData\Local\JetBrains\Toolbox\apps\CLion\ch-0\211.7442.42\bin\cmake\win\bin\cmake.exe --build C:\Users\joel\Documents\projects\malloy\cmake-build-debug --target malloy-example-server-session
[1/3] Building CXX object examples/server/session/CMakeFiles/malloy-example-server-session.dir/main.cpp.obj
[2/3] Building CXX object lib/malloy/CMakeFiles/malloy-objs.dir/server/routing/router.cpp.obj
FAILED: lib/malloy/CMakeFiles/malloy-objs.dir/server/routing/router.cpp.obj 
C:\msys64\mingw64\bin\c++.exe -DBOOST_BEAST_USE_STD_STRING_VIEW -DBOOST_DATE_TIME_NO_LIB -DMALLOY_FEATURE_TLS -DSPDLOG_COMPILED_LIB -DUNICODE -DWIN32_LEAN_AND_MEAN -D_UNICODE -I../lib/malloy/client/3rdparty -I../lib/malloy/.. -I/lib/include -I/lib -I_deps/spdlog-src/include -isystem C:/OpenSSL/include -g -Wa,-mbig-obj -O3 -std=gnu++2a -MD -MT lib/malloy/CMakeFiles/malloy-objs.dir/server/routing/router.cpp.obj -MF lib\malloy\CMakeFiles\malloy-objs.dir\server\routing\router.cpp.obj.d -o lib/malloy/CMakeFiles/malloy-objs.dir/server/routing/router.cpp.obj -c ../lib/malloy/server/routing/router.cpp
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/as.exe: lib/malloy/CMakeFiles/malloy-objs.dir/server/routing/router.cpp.obj: section .rdata$_ZTVN5boost5beast12basic_streamINS_4asio2ip3tcpENS2_9execution12any_executorIJNS5_12context_as_tIRNS2_17execution_contextEEENS5_6detail8blocking7never_tILi0EEENS5_11prefer_onlyINSC_10possibly_tILi0EEEEENSF_INSB_16outstanding_work9tracked_tILi0EEEEENSF_INSJ_11untracked_tILi0EEEEENSF_INSB_12relationship6fork_tILi0EEEEENSF_INSQ_14continuation_tILi0EEEEEEEENS0_21unlimited_rate_policyEE3ops11transfer_opILb0ENS2_15const_buffers_1ENS2_6detail8write_opISZ_NS2_14mutable_bufferEPKS15_NS13_14transfer_all_tENS2_3ssl6detail5io_opISZ_NS1A_8write_opINS0_19buffers_prefix_viewINS0_6detail11buffers_refINS1D_IRKNS0_14buffers_suffixINS0_16buffers_cat_viewIJNS1F_INS1H_IJNS2_12const_bufferES1I_S1I_NS0_4http12basic_fieldsISaIcEE6writer11field_rangeENS1J_10chunk_crlfEEEEEENS1J_6detail10chunk_sizeES1I_S1P_S1I_S1P_S1I_S1I_S1P_EEEEEEEEEEEEENS0_11flat_streamINS19_6streamISZ_EEE3ops8write_opINS1S_13write_some_opINS1S_8write_opINS1S_12write_msg_opINS1E_18bind_front_wrapperIMN6malloy6server4http10connectionINS2E_14connection_tlsEEEFvbNS_6system10error_codeEyEJSt10shared_ptrIS2G_EbEEENS0_10ssl_streamISZ_EELb0ENS1J_15basic_file_bodyINS0_10file_stdioEEES1M_EES2Q_NS1S_18serializer_is_doneELb0ES2T_S1M_EES2Q_Lb0ES2T_S1M_EEEEEEEEEE: string table overflow at offset 10000487
C:\Users\joel\AppData\Local\Temp\ccM9wQke.s: Assembler messages:
C:\Users\joel\AppData\Local\Temp\ccM9wQke.s: Fatal error: lib/malloy/CMakeFiles/malloy-objs.dir/server/routing/router.cpp.obj: file too big
ninja: build stopped: subcommand failed.

As @0x00002a mentioned it might be worth separating things out into dedicated libraries for server & client. I fully agree that this should be done in the future. However, as I understand, the problem is based on the resulting translation unit(s) exceeding limits and I don't think that separating the resulting library components will affect that?

[0x00002a]

@Tectu I got something. I can't compile if I use msys2's boost package installed via pacman, I get the file too big error (the boost installed via msys is 1.75.0 not sure if that matters). If I just set BOOST_ROOT env variable to point to an extracted version of one of these (which is also what the CI does) then it works (on my machine :p).

[Tectu]

I gave this a try. Results:

• boost 1.74.0: build successful
• boost 1.75.0: build failed with problem indicated in this issue
• boost 1.76.0: build successful

[0x00002a]

Well that's weird because the CI can build it even with 1.75.0. Must be something up with msys2's packaging of that version?

[Tectu]

Shouldn't be related to the msys2 package. With all three versions I downloaded the archives from boost.org and used BOOST_ROOT accordingly. I verified each time that the output of cmake reports back the expected boost version.

[0x00002a]

Is it acceptable for the library not to build with boost 1.75.0 on mingw? Can msys2 install a later version currently, since if not I guess thats a no

[Tectu]

No problem for my side not to support boost 1.75.0. However, I see two issues with that:

• CMake's find_package() does not seem to allow specifying invalid/non-supported versions. Only required minimum or exact versions.
• This seems like working around another issue. It would be good to figure out if this is due to a "bug" in boost 1.75.0 or whether we're just "lucky" because the file structuring or some default options changed and future boost versions might trigger the same problem.

We can always add custom logic to the cmake scripts to error when boost 1.75.0 is found but that would be specific to the MinGW/Msys2 situation. Given that the build simply fails we might just document this accordingly instead. Might be the more proper solution.

In general this situation just triggers some alarm bells. What do you think?

[0x00002a]

Agreed, it could very easily be a coincidental fix. Especially since I can't find anything in the changelogs to suggest this was an issue they specifically addressed (although it might be buried somewhere in a boost lib other than beast). I don't like it but I'm not sure we can fix this since I don't even know what causes the issue in the first place, other than its probably something to do with the template stuff introduced in #14.

I did look at the diffs between 1.75 and 1.76 for beast and they did change a bunch of stuff around tls, that might've simplified the templates a bit and allowed it to build but thats just guesswork.

Could connection be implemented without CRTP? I'm wondering if connection_t (variant of all the derivatives of connection) might've caused this. Might be worth trying it if it can be simply done just to see. We do need to pin the type down somewhere so it can be passed across the inheritance boundry of endpoint_http and/or stored somewhere to actually send messages with

[Tectu]

As discussed, the best thing would be to add CI capabilities for building this library with MinGW to catch problems like this.
I've created #27 for that.