Am 19.05.2008 um 09:44 schrieb Jean-Daniel Dupas:
Le 19 mai 08 à 01:17, Andy Wiese a écrit :
On May 16, 2008, at 11:15 PM, David M. Cotter wrote:
is this the right list? where should i go for help with this? is anybody... <echo>out there</echo>?
On May 16, 2008, at 3:40 PM, David M. Cotter wrote:
i want to compile CoreFoundation and CFNetwork on windows in such a way that i can link it with my CodeWarrior project.
yes i'm using CodeWarrior on windows to compile my project. and i want to use CFStrings, CFDictionaries and CFNetwork.
the doc sez to use CygWin to compile CF stuff. well okay fine, so i should not compile it with CodeWarrior.
first: is this the right list?
second: can i do this? or am i better off attempting to compile the whole shebang in CodeWarrior?
or third: has somebody DONE this and can i just have the binary so i can get to work?
David,
I'm in the discovery stage of a project which is quasi-reverse from yours--I have a static library which builds in CodeWarrior Win32, and I'm trying to port it to generic make + gcc on Win32 (and linux, os-x). I don't have any clear answers for you, but I'd be interested in sharing tips and pitfalls off-list if you're interested.
I don't want to hijack your thread, but here's a couple observations on topic with your question:
For the build environment on Windows, common wisdoms seems to be that to build a Win32 library that links to a regular win32 runtime with no deps on cygwin, I should use MinGW. I have found MinGW/MSYS to be a pain in the arse so far. I haven't gotten a definitive answer about whether cygwin gcc can be used to build the same product (no runtime deps on cygwin). Any experts out there care to pipe in?
Well let's hijack some more. I'm not quite sure I understand the question. But it used to be, that you had to decide if you want to go with cygwin, or MinGW, because the two would cause problems because of DLL conflicts, but that was some time ago that I had to deal with this issue. Cygwin tries to give you a full POSIX environment, and has a larger runtime, but should allow to build any POSIX/UNIX source without problems, but then your Application will be at home and talking to the Cygwin environment as far as directories and such go.
I'd recommend to use cygwin only if you have very UNIXy programs that will be hard to adapt to a Windows environment, and deal with the dependencies.
With MinGW's gcc 3.4.5, I found a bug with precompiled headers and '#pragma once', which forced me to use gcc 4.x. I couldn't get gcc 4.x to work right until I downloaded an entire MSYS/MinGW distro from
http://nuwen.net/mingw.html I wish I had found that distro earlier, because patching together a working MSYS/MinGW has been very frustrating. The sourceforge download site is byzantine. However, now that I am using nuwen's distro the 'find' command seems to be broken (which is critical to my makefile), so I'm not out of the woods yet.
As far as Installation of MinGW/MSYS goes, I did it twice as well. Recommendation: Stick with the path-names and directory-structure provided in the Documentation/FAQ and don't get creative, it's good for you!
I worked for years on a project with a large static library built for Xcode, CodeWarrior/Mac and CodeWarrior/Win32. I was our belief that we couldn't use libs built on one compiler in an app built with the other. But our lib was C++ so it may have been language issues and possibly plain C would work better.
This is a nightmare and in most cases not remotely possible. With C++ name-mangling being completely non-standard (until recently) and changing from minor version to minor version (gcc 2.x), this would only work with certain compilers and a restricted subset of the C++ language (Sun Pro 5.x to 6.x had this facility if memory serves me right).
This is the reason my former employer shipped the C++ wrapper of their API as source, since the C stuff would not mind too much when used on a different compiler, or if there was some slight mismatch in versions.
Do you know the Cocotron project ? This is a rewrite of Cocoa for Linux and Windows. The interesting part is that this project include a cross gcc 4.3 version that run on OS X and generate Win32 object/executable/dll.
If you can work with Xcode as a build environment, it is interesting, though there are quite some holes in the Objective-C libraries, so be careful on what you need, but it builds very nicely, just start the shell-script and wait for it to finish.