User forums > General (but related to Code::Blocks)

TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)

<< < (9/9)

grf:

--- Quote from: TDragon on September 29, 2013, 12:36:18 am ---Some TDM-specific changes since the last release:

* TDM-GCC now uses POSIX-style threads in its runtime libraries by way of the MinGW-w64 "winpthreads" layer. This allows std::thread and other C++11 pthreads-based features to be used.
* TDM-GCC's version of winpthreads is patched for fully static use, so you won't be distributing an additional pthreads DLL with your programs. The patch gives winpthreads the ability to share thread handles among DLLs and EXEs.
* By popular request, the "-static-libstdc++" option is back. It doesn't do anything, because TDM-GCC uses a static libstdc++ by default and you have to use "-shared-libstdc++" to get the DLL version, but it doesn't cause a compile-time error anymore.
* By dint of some upstream work and some TDM-GCC-specific hacking, the Ada language is finally available for the TDM64 edition (32-bit or 64-bit compilation).
--- End quote ---

Interesting changes. However, the new tdm-gcc 4.8.1 (32 Bit version) created for my wxWidgets project a binary, which consumes a lot more CPU power than the version before, which was compiled with tdm-gcc 4.7.1. It's a single threaded application and the profiler told me, that about 50% of the runtime was lost in the both functions _spin_lite_lock and _spin_lite_unlock...  :o
Unfortunately I have no idea where to look for the reason...

TDragon:
Interesting report. Those functions are part of the winpthreads layer used to implement threading functions in libgcc and libstdc++.

Coincidentally, the spinlock portion of winpthreads has been rewritten since the TDM-GCC 4.8.1 release. We'll see if the next release exhibits any improvements.

-John E. / TDM

stahta01:

--- Quote from: ToApolytoXaos on October 23, 2013, 04:33:50 pm ---
Also, another serious issue is with existing wxMSW projects I have already created. I have tried to recompile them with the currently compiled files, and it seems there's an issue with .rc files:


--- Code: ---||=== Build: Debug in wxCartridgeStockTaking (compiler: GNU GCC Compiler) ===|
C:\Users\stefanos\GENERAL\Projects\WXPROJ~1\WXCART~1\resource.rc|3|fatal error: wx/msw/wx.rc: No such file or directory|
||can't open icon file `wx/msw/std.ico': No such file or directory|
||preprocessing failed.|
||=== Build failed: 3 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

--- End code ---

With tdm's gcc 4.7.1 (32-bit), I did not have such issue before. Anyone else had anything similar to this?

--- End quote ---

That "wx/msw/wx.rc" message is 90% of the time because of a bad/missing CB search path.
Remember this is the search path for the "resource compiler" not the linker or normal compiler.

Tim S.

ToApolytoXaos:

--- Quote from: stahta01 on February 01, 2014, 01:46:31 am ---That "wx/msw/wx.rc" message is 90% of the time because of a bad/missing CB search path.
Remember this is the search path for the "resource compiler" not the linker or normal compiler.

Tim S.


--- End quote ---
Hey Tim S., thanks for the reply. I have discovered the issue a long time ago and thought it was my problem, but seems it does it occasionally without any "warning" or whatsoever.

I have had created projects in the past with wxMSW-2.8.10, set my global variable names in Build options... > Search directories with standard C::B naming, like $(#wx.include) and so forth, and for some reason it would replace the variables with full expanded path; for example, C:\wxMSW-2.8.10\include etc etc.

That is why it would fail to build them with wxMSW-2.8.12, because the path it would look for, it would not exist anymore as I have removed it in favor of wxMSW-2.8.12.

Yes, I saved the project to accept any changes; besides, it would not let me close the project without accepting or discarding any project changes upon exit. It does not do this every time though; it happens from time to time, only on Windows of course.

stahta01:

--- Quote from: ToApolytoXaos on February 01, 2014, 09:50:14 am ---
--- Quote from: stahta01 on February 01, 2014, 01:46:31 am ---That "wx/msw/wx.rc" message is 90% of the time because of a bad/missing CB search path.
Remember this is the search path for the "resource compiler" not the linker or normal compiler.

Tim S.


--- End quote ---
Hey Tim S., thanks for the reply. I have discovered the issue a long time ago and thought it was my problem, but seems it does it occasionally without any "warning" or whatsoever.

I have had created projects in the past with wxMSW-2.8.10, set my global variable names in Build options... > Search directories with standard C::B naming, like $(#wx.include) and so forth, and for some reason it would replace the variables with full expanded path; for example, C:\wxMSW-2.8.10\include etc etc.

That is why it would fail to build them with wxMSW-2.8.12, because the path it would look for, it would not exist anymore as I have removed it in favor of wxMSW-2.8.12.

Yes, I saved the project to accept any changes; besides, it would not let me close the project without accepting or discarding any project changes upon exit. It does not do this every time though; it happens from time to time, only on Windows of course.

--- End quote ---

Are you positive you used "$(#wx.include)" instead of $(#wx)/include) or $(#wx)\include) because I never had it happen to me.
But, I use "$(#wx.include)" all the time.

Tim S.

Navigation

[0] Message Index

[*] Previous page