Sorry if you feel angry and not all person in the world having the same views like
you. There is no Problem and nothing needs to solve - what you talking about?

Am 30.12.2011 11:57, schrieb JonY:
On 12/30/2011 18:14, Peter Meyer wrote:
Am 30.12.2011 10:06, schrieb JonY:
You should be recompiling GTK for win32 also, you can't use native
libraries when cross compiling. You may also want to build a specially
modified pkg-config for cross compiles, eg i686-w64-mingw32-pkg-config
that points to your special PKG_CONFIG_PATH for your Win32 GTK libraries.
Sorry, but i dont do thadt.I have a solution on Win64 and Win32-Systems 
and thadt works. On Linux/Unix this is an diffrent story but not on 
Microsot Windows .
Windows is not an posix System and it will never.I on Windows the best 
Solution is using Cmake and avoid posix only things Cygwin at all. CMake 
works fine and is real Crossplatform and 10.000 times faster than the 
ugly autotool stuff ;D
This is already a solved problem, made into a big issue with your
insistence to use custom makefiles and failing to understand the basics
of using a cross compiler. If only you took some initiative to
understand what you are actually doing, you won't run into any issues,
cmake or not. I don't understand why you are making this difficult for

Ditto, you mixed Cygwin with non-Cygwin, don't do that, cross compile 
all the dependencies as well.
Again, thanks but no thanks.If i can, then i use GCC/G++ but if this is 
not possible, i have to target Visual C/C/++ or
SUN/Oracles C/C++ Compiler as well.
Likewise, autotools already handles that nicely. It even knows about
MSVC already. Good luck maintaining multiple build systems that all need
to be updated to accommodate different scenarios.

I just tested the 32-Bit build on Windows 2000 32-Biz SP4 with latest
patches but there is an Error:"Entry Point Not Found The procedure entry
point ___lc_codepage_func could not be located in the dynamic linl
library msvcrt.dll" I just investigating this problem right now.

This is a problem with the older toolchains, it has been fixed some time
ago, you may need to update your mingw-w64 install and/or recompile your
code. IIRC this problem plagues early XP SP0 and Win2K (Win2K isn't
exactly supported by mingw-w64, so anything goes).
Hmm, i read a diffrent post from Kai Tiez

[quote]mingw-w64 does not support Windows OSes below XP officially.[/quote]

This explain a lot to me.Ok, if i want,  i could built mingw64, GTK, 
Boost and anythin i needed from scratch, but this is an oververhead and 
like Kai explains: "This may work, but it is not officially supported". 
So i think i will compile my Projects on Win x64 with mingw64  4.5.x  
and on Win32 with MinGW 4.5.x wich runs out of the box on Win2000
Systems up to Win8 on Win32 Targets (i have used it in an QT4Project and 
it works flawless) On top of this i will use Cmake, it was build for 
Crossplatform and Cross Compiler
builts and it is 10.000 times faster than the ugly Autotools ;D

I guess you can't tell the difference between a compiler host, target
system, C Runtime and a buildsystem, you managed to mangle them all
together. Try again next time.

Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free!

Mingw-w64-public mailing list