User forums > General (but related to Code::Blocks)
TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
gd_on:
And another thing, not related to the previous problem, and not related to C::B, but more to tdm gfortran.
I tried to detect in a fortran program if it's compiled in 32 or 64 bits.
On your previous site, you said we could use conditional compilation. I tried such a code :
--- Code: --- PROGRAM hello
! Does not work ?
#ifdef _WIN32
#ifdef _WIN64
print *, "Windows 64 bits compiler"
#else
print *, "Windows 32 bits compiler"
#endif
#endif
print *, "hello there Does this program work"
END
--- End code ---
using -cpp during compilation to activate preprocessing.
But it does not work.
I remember that you said on your previous site version that those environment variables where set if you compile with 32 and/or 64 bit compiler. But I have not found this on your new design.
Do I miss something here too ?
It's not special to 4.81 version, was already there with 4.71.
gd_on
TDragon:
As of now, the installers have been reverted to use the older stable releases of w32api (3.17-2) and mingwrt (3.20-2) until MinGW.org releases fixed versions.
--- Quote from: MortenMacFly on September 29, 2013, 06:02:38 pm ---Did you (or anyone else in this forum) try to compile wx 2.8.12 with this version?
I get tons of errors, starting with:
../../src/msw/treectrl.cpp:2581:17: error: 'NMTVDISPINFOWW' was not declared in this scope
TV_DISPINFO *info = (TV_DISPINFO *)lParam;
...and thats it. Additionally the build log is flooded with deprecated warnings concerning win API headers.
--- End quote ---
My bad. I built wxWidgets and Code::Blocks with TDM-GCC 4.8.1 and MinGW.org's w32api-3.17, but released with MinGW.org's w32api-4.0.3 instead without testing it. I'll revert the installers in a little bit, which should fix this problem. (Users who installed before I revert will need to run the installer and intentionally select the older mingw-rt and w32api versions; it won't select them for you because it will detect them as being older versions, which they are.)
TDragon:
--- Quote from: gd_on on September 29, 2013, 07:13:25 pm ---And another thing, not related to the previous problem, and not related to C::B, but more to tdm gfortran.
I tried to detect in a fortran program if it's compiled in 32 or 64 bits.
--- End quote ---
Sorry, I don't know much about compiling with GFortran. Apparently it doesn't define those particular macros.
--- Quote ---I remember that you said on your previous site version that those environment variables where set if you compile with 32 and/or 64 bit compiler. But I have not found this on your new design.
--- End quote ---
I judged this information was no longer relevant enough to post on the site. You can dump a listing of predefined macros with the following command:
gcc -dM -E - <nul
Tack on flags after the "gcc" if you want to see how they affect it.
ollydbg:
The information below gives some hint on how to choose sjlj or dw2 version of TDM-GCC when building wxWidgets lbirary.
I read a blog from VZ (a wxWidgets developer), http://wxwidgets.blogspot.com/2011/06/choosing-gcc-for-building-wxwidgets.html
--- Quote ---And second, MinGW64 uses the so-called SJLJ exceptions which can propagate through the code not compiled with gcc, e.g. all Windows system DLLs. And in practice this is needed to be able to catch any exceptions thrown by your wxWidgets event handlers. So while DW2 exceptions used by MinGW version do have their advantages (in particular they are much more speed-efficient), SJLJ ones are preferable for wxWidgets GUI applications.
--- End quote ---
So, he suggest using SJLJ edition.
Here is my testing result of how c++ exception works under wx, the sample is under \wxWidgets-2.8.12\samples\except, see image below
Condition: wx lib build from TDM-GCC 4.8.1 dw2 ---> Result: crash on any c++ exception from event handler (the crash also happens in wx lib build from PCX-GCC 4.6.3 dw2), see image below:
Condition: wx lib build from TDM-GCC 4.7.1 sjlj ---> Result: exception can catch correctly, no crash, see image below:
I have not tried TDM-GCC 4.8.1 sjlj, I think it is the same as TDM-GCC 4.7.1 sjlj.
BTW: I can successfully build wx 2.8.12 with TDM-GCC 4.8.1 dw2. (I have use the tdm-gcc-webdl.exe, you should to down grade the mingw crt to stable version)
EDIT: it looks like wxWidgets' sample excep program should work for all kinds of exception models GCCs (both sjlj and dw2), because there are no exceptions cross non-mingw stack, so I suspect it is a bug in TDM-GCC, see this post for details.
gd_on:
On a PC at work, I have finally been able to compile C::B with tdm 4.81 gcc ;). On this PC I have not the problem of "mingw32-gcc.exe - No disk; There are no disk in the drive. Insert a disk in \Device\Harddisk4\DR4", that I met on my own PC, at home >:(!
I use also the last updated tdm version with winapi 3.17.
Nevertheless, I have made a small modification within wxWidgets 2.8.12, because compile time was too huge, due to apparently the back tracking of a warning: there were so many warnings that after 4 hours of messages :o, I decided to stop compilation and tried to find a workaround. I had tons of messages like this one:
--- Code: ---C:\wxWidgets-2.8.12\include/wx/debug.h:194:43: warning: typedef 'wxDummyCheckInt' locally defined but not used [-Wunused-local-typedefs]
#define wxFORCE_SEMICOLON typedef int wxDummyCheckInt
^
C:\wxWidgets-2.8.12\include/wx/debug.h:224:9: note: in expansion of macro 'wxFORCE_SEMICOLON'
wxFORCE_SEMICOLON /* just to force a semicolon */
^
C:\wxWidgets-2.8.12\include/wx/debug.h:233:38: note: in expansion of macro 'wxCHECK2_MSG'
#define wxCHECK_RET(cond, msg) wxCHECK2_MSG(cond, return, msg)
^
C:\wxWidgets-2.8.12\include/wx/buffer.h:289:9: note: in expansion of macro 'wxCHECK_RET'
wxCHECK_RET( m_bufdata->m_data, wxT("invalid wxMemoryBuffer") );
^
.....
--- End code ---
in my C:\wxWidgets-2.8.12\include\wx folder, I have modified line 194 in debug.h:
original code:
--- Code: ---#define wxFORCE_SEMICOLON typedef int wxDummyCheckInt
--- End code ---
replaced by:
--- Code: ---#define wxFORCE_SEMICOLON struct wxDummyCheckStruct /*typedef int wxDummyCheckInt*/
--- End code ---
This is just a hack, because like that it's the same code for gnu and non-gnu gcc compilers, but it works.
Like that, I have been able to compile wxWidget 2.8.12 with gcc 4.8.1, with largely less warnings that without my hack (there are still a few ones!).
And build a new C::B version with gcc 4.81 too (in a few minutes, as usual).
I was not totally sure it will work because of the chicken and egg problem: who is the first?
Effectively, my old version of C::B was compiled with tdm 4.71, my new wxWidgets libraries and dll were compiled with gcc 4.81. But after some tries, it's OK.
Certainly, the order in which you build wxWidgets and intermediate C::B versions is important, because at certain step I had mixed things between 4.71 and 4.81 versions.
If this can help ...
gd_on
[attachment deleted by admin]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version