Legacy support request, so sorry for that (4.2.177)

Hello. I compiled 4.2.177 (with my modifications, that’s why it’s so old) on Vista with TDM-GCC32 and caught an awful bug.

I used GTKMM 2.22 development package. My release ( -O3 ) version fails here:
libglibmm-2.4-1.dll
with exception 0xC0000005 .
My debug version ( -O0 ) fails here:
msvcrt.dll

with following backtrace:

(gdb) bt
#0  0x75ddeb6a in strlen () from C:\Windows\system32\msvcrt.dll
#1  0x6652ea69 in length (__s=<optimized out>)
    at /W64_4.4_164235-src/build-gcc/i686-w64-mingw32/libstdc++-v3/include/bits/
char_traits.h:263
#2  std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basi
c_string (this=0xdca11e <_ZN8rtengineL7MAXVALDE+12486>,
    __s=0xeefa7b2c <Address 0xeefa7b2c out of bounds>, __a=...)
    at /W64_4.4_164235-src/build-gcc/i686-w64-mingw32/libstdc++-v3/include/bits/
basic_string.tcc:216
#3  0x664de158 in Glib::ustring::ustring (
    this=0xdca11e <_ZN8rtengineL7MAXVALDE+12486>,
    src=0xeefa7b2c <Address 0xeefa7b2c out of bounds>) at ustring.cc:318
#4  0x00a55128 in __static_initialization_and_destruction_0 (
    __initialize_p=1, __priority=65535)
    at d:/Programs/gtkmm/include/gtkmm-2.4/gtkmm/papersize.h:41
#5  0x00a5523f in _GLOBAL__sub_I__ZN6rtexif14stdInterpreterE ()
    at F:\rt\working\rtexif\rtexif.cc:2423
#6  0x00a74a4a in __do_global_ctors ()
#7  0x004010dc in __mingw_CRTStartup ()
#8  0x00401295 in mainCRTStartup ()
(gdb)

The weirdness here is that program crashes at static and global variables initialization and I cannot decypher this backtrace. papersize.h:41 is const Glib::ustring PAPER_NAME_A3 = "iso_a3"; and that is hella weird as well, the constructor of this ustring gets &MAXVALD variable (if I understand it correctly) from completely unrelated part of program as this and completely bad memory address as initialization source.

So, there is something terribly wrong and I do not have a slightest clue about how to fix it. Googling this does not help. I tried copying libraries from 4.2.1 release, with samish result. 4.2.1 runs fine, the same code compiled with same version of TDM-GCC for 64bit and same version of GTKMM runs fine on other machine.

My cmake command is
cmake -DCMAKE_BUILD_TYPE=%RT_BUILD_TYPE% -D_WIN32_WINNT=0x0502 -DCMAKE_C_FLAGS="-O3 %RT_SSE_SUPPORT%" -DCMAKE_CXX_FLAGS="%CMAKE_C_FLAGS%" -DBUILD_BUNDLE:BOOL="1" -DCACHE_NAME_SUFFIX:STRING="%RT_CACHE_VER%" -G "MinGW Makefiles" -DPROC_TARGET_NUMBER:STRING=2 %RT_SOURCECODE_PATH% and same for debug with -O0.

Here are release execs to try it out if anyone wants it by a pure chance (you may unpack them to existing 4.2.1 installation): https://filebin.net/yrvli0rfvgqbza60

Why don’t you try to use your modifications with current code?

If profile format did not change and general structure of processing pipeline and settings had not changed dramatically, I might as well do it.

You could try to use MSYS2 as described here

I almost rejected this idea but
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

so I can use exactly the same libraries with the only GCC I can get from pacman (one of the most recent ones, not 4.9.*). I might try that!

BTW, how does toolchain prefix gets passed to Cmake? Won’t the described method use non-prefixed GCC?

If you run into problems, just ask, though I can not promise solutions.

What do you mean by prefixed or non-prefixed gcc ?

NVM, I figured it out. In Cygwin and other POSIX systems there are prefixed executables for every toolchain except main one but it seems that in MSYS2 they are not prefixed but stored in separate folder.

I might only wonder why pacman does not install GCC 6.3.0 and 7.1.0 which are clearly in REPOS in sf.net project dir already, just 6.2.0 but that does not matter too much.

I am probably getting too much warnings because GCC assumes C++11 standard and linking fails with C++11-related errors, what standard should be chosen? C++03?

Trying -std=gnu++98 now (default for 4.9.2).

Okay I gave up with 4.2, 5.2 compilation is a bliss though.