tdm-mingw

TDM-GCC w64 script to change windres for 32bit?

不羁岁月 提交于 2019-12-01 20:10:28
问题 Trying to get the TDM-GCC(4.7.1) running on XP SP3 - I just need a c++ 32bit build for now. It seems that windres is not in the right format, my .rc file is failing the build: x86_64-w64-mingw32-g++.exe -Wall -m32 -s -D_M_X86 -DBUILD_DLL -DNDEBUG -c C:\SynthEditSDK\TD_SV\SV.cpp -o obj\Release\TD_SV\SV.o windres.exe -J rc -O coff -i C:\SYNTHE~1\TD_SV\TD_SV.rc -o obj\Release\TD_SV\TD_SV.res x86_64-w64-mingw32-g++.exe -shared -Wl,--output-def=bin\Release\libTD_SV -Wl,--out-implib=bin\Release

What is the difference between Orwell's MinGW and TDM Dev-C++ versions?

徘徊边缘 提交于 2019-11-30 06:31:25
问题 I am a newbie at this and yesterday I installed Win 8.1 x64 so I would like to use the most suitable program for making my tasks in C/C++. Thanks 回答1: MinGW supports only 32 bit binaries, TDM supports 32 and 64 bit binaries (with usage of MinGW's API's). If you need a good GCC for Windows, with the drawback of 32 bit only, use MinGW . If you want to build 64 bit binaries too, you can use TDM . Both released GCC 4.8 approximately at the same time, so there's no real difference in up-to

How to see what g++ command-lines Boost.Build invokes (1.33.1)

孤街醉人 提交于 2019-11-30 05:28:38
问题 I'm scratching my head, trying to figure out why the import libraries are not generated when I build the Boost libraries on my machine. More specifically, building the DLLs works fine, but where I would previously (i.e. before I reinstalled my machine) generate the import libraries correctly. Some specs: Boost 1.33.1 g++ 4.3.3 TDM-1 release for Windows Building with gcc toolset from MS Dos command-line prompt UnxUtils (after 14-04-03) The command-line that invokes bjam.exe looks like this: "C

C++ inline functions using GCC - why the CALL?

夙愿已清 提交于 2019-11-29 00:58:09
问题 I have been testing inline function calls in C++. Thread model: win32 gcc version 4.3.3 (4.3.3-tdm-1 mingw32) Stroustrup in The C++ Programming language wirtes: The inline specifier is a hint to the compiler that it should attempt to generate code [...] inline rather than laying down the code for the function once and then calling through the usual function call mechanism. However, I have found out that the generated code is simply not inline. There is a CALL instrction for the isquare

What is the difference between Orwell's MinGW and TDM Dev-C++ versions?

夙愿已清 提交于 2019-11-28 19:32:46
I am a newbie at this and yesterday I installed Win 8.1 x64 so I would like to use the most suitable program for making my tasks in C/C++. Thanks ollo MinGW supports only 32 bit binaries, TDM supports 32 and 64 bit binaries (with usage of MinGW's API's). If you need a good GCC for Windows, with the drawback of 32 bit only, use MinGW . If you want to build 64 bit binaries too, you can use TDM . Both released GCC 4.8 approximately at the same time, so there's no real difference in up-to-dateness. My recommendation: Use the 3rd alternative : MinGW-w64 instead - it's a extended MinGW with support

Multiple definition of inline functions when linking static libs

非 Y 不嫁゛ 提交于 2019-11-27 01:04:47
I have a C++ program that I compile with mingw (gcc for Windows). Using the TDM release of mingw which includes gcc 4.4.1. The executable links to two static library (.a) files: On of them is a third-party library written in C; the other is a C++ library, written by me, that uses the C library provides my own C++ API on top. An (in my view, excessive) portion of the C library's functionality is implemented in inline functions. You can't avoid including the inline functions when you use the C library's API, but when I try to link it all together, I'm getting link errors saying there is a

Multiple definition of inline functions when linking static libs

谁说胖子不能爱 提交于 2019-11-26 17:28:03
问题 I have a C++ program that I compile with mingw (gcc for Windows). Using the TDM release of mingw which includes gcc 4.4.1. The executable links to two static library (.a) files: On of them is a third-party library written in C; the other is a C++ library, written by me, that uses the C library provides my own C++ API on top. An (in my view, excessive) portion of the C library's functionality is implemented in inline functions. You can't avoid including the inline functions when you use the C