From: Peter M. <pm...@ya...> - 2011-12-30 11:39:48
|
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 > yourself. > >>> 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] >> http://sourceforge.net/support/tracker.php?aid=3382873 >> >> 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! http://p.sf.net/sfu/Citrix-VDIinabox > > > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public |