Legacy support request, so sorry for that (4.2.177)

(Euri Pinhollow) #1

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:
with exception 0xC0000005 .
My debug version ( -O0 ) fails here:

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/
#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/
#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 ()

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

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

(Ingo Weyrich) #2

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

(Euri Pinhollow) #3

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

(Ingo Weyrich) #4

You could try to use MSYS2 as described here

(Euri Pinhollow) #5

I almost rejected this idea but

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!

(Euri Pinhollow) #6

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

(Ingo Weyrich) #7

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

(Ingo Weyrich) #8

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

(Euri Pinhollow) #9

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.

(Euri Pinhollow) #10

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.

(Euri Pinhollow) #12

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).

(Euri Pinhollow) #13

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