For what its worth I'm pretty sure that I am using the vanilla Mingw install, not the TDM one. My notes say that I started here:

http://www.mingw.org/wiki/Getting_Started

and in Msys versions are:

uname -A MINGW32_NT-5.1 MYPC 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys gcc --version gcc.exe (GCC) 4.6.2 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

No indication of "TDM" anything, and inkscape builds fine for me.

Also

/c/progs/mingw/var/log/mingw-get-log.txt

does not have the string "tdm" in it anywhere and all the downloads were from:

http://prdownloads.sourceforge.net/mingw/

Is there some other way to tell if Mingw is the TDM one?

Remind me again why TDM is suggested?

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

On 10/27/2012 01:41, JonY wrote:

On 10/27/2012 01:21, JonY wrote:

...

On 10/25/2012 22:50, Arshdeep Singh wrote:

...

Hello, Unfortunately, there is some problem with the build file or something wrong with the inkscape.exe. I have tried compiling on another machine on Windows 7 x64 only to face the same problem.

The problem is: the build process completes successfully without errors but the inkscape.exe runs for a few seconds (seen in the task manager) and then quits. No windows opening, no send error report messages. Just a 'inkscape.exe' process in the task manager.

Compiled by following the below page word to word: http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows

Compiler: TDM-GCC 4.7.1 Mingw32 bit edition and not the experimental 32 cum 64 bit one.

Take note that 4.7.x series is now defaulting to __thiscall call convention for C++ member methods. In short, C++ code built by previous versions will NOT work.

So, somebody needs to rebuild the precompiled libraries for the new version. In fact, you should be building the libraries for each flavor and version of toolchain, rather than the one-size-fits-all system that you have now, C++ ABI is rather unstable if compiler configuration is different.

Some info from IRC says TDM is the preferred compiler toolchain, make sure all the users stick to the same toolchain and version.

I've noticed libgcc_s_sjlj-1.dll in the devlibs, that means using the SJLJ version from TDM. That also means no mixing with GCC from the official mingw.org.

I can update http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows if somebody offers an account.

On 10/27/2012 02:18, mathog wrote:

On 26-Oct-2012 10:21, JonY wrote:

...

Take note that 4.7.x series is now defaulting to __thiscall call convention for C++ member methods. In short, C++ code built by previous versions will NOT work.

Is there some reason not to set a compiler flag to make 4.7.x use the same call convention as the older 4.6.x? Is there any advantage for either the developers or the end users in using the newer call convention?

No, there is no such flag.

Neither would it be practical to implement it, the libstdc++ C++ library used by GCC will not work with a different call convention it was built with.

As for advantages, there aren't any clear performance winners other than a slight increase in MSVC compatibility.

The previous call convention is __cdecl[1], arguments pushed to stack right to left, caller unwinds the stack. This convention is used by Linux SysV ABI and normal C code on Linux and Windows. __thiscall[2] is a C++ variant of __stdcall[3] where stack is unwound by callee, however the "this" C++ context is put on the ECX register rather than as a normal first call argument.

GCC unfortunately does not mangle __cdecl vs __thiscall call convention into the object symbol tables, this meant you can still link your old code, but it would fall apart during runtime.

[1] http://msdn.microsoft.com/en-us/library/zkwh89ks.aspx [2] http://msdn.microsoft.com/en-us/library/ek8tkfbw.aspx [3] http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx