On 2005.10.13 at 12:42:34 -0700, Howard Chu wrote: > > We already build using the mingw32 compiler under msys. I've been a bit > lax about sending back patches lately, but as I recall there were only a > few small tweaks to Configure needed. IMO the Cygwin environment is > worthless; it is several times slower than MinGW/MSYS for no real benefit.
I wouldn't agree that Cygwin environment is completely worthless. At least while there is no sshd in MSys. Cygwin enviornment is quite a good tool for extending mulitplatform Unix-based automated building-testing frameworks to win32 platforms. It is often not important if nightly build on one particular platform runs fifteen minutes or couple of hours, since other builds are done in parallel on other machines anyway. > >>Resulting libraries are in all` cases compatible with Microsoft Visual C. > > >In addition #2 should/will generate .def files and use them when linking > >.dll. Idea is to be able to generate drop-in replacement .dlls for those > >compiled with MSVC. It is not done yet? With all the infrastructure in place? I'd look there. > > >>GNU C cross-compilers can be invoked in two ways > >> > >>1. Using -B option to gcc > >>2. Using name which looks like <architecture>-<system>-gcc, in this case > >> i586-mingw32msvc-gcc. > >>I recommend using the second way, because we need to call > >>cross-versions of some binutils programs, such as ranlib, and they do > >>not have -B option. > > > >I'd create a /some/place/i586-mingw32mscv catalog, create small wrapper > >scripts called gcc, ranlib, etc. with 'exec i586-mingw32mscv-$0 "$@"' > >line, and prepend your $PATH with /some/place/i586-mingw32mscv prior > >running make:-) A. > > I've done this type of setup before, with complete toolchains in > /some/place/<architecture>. You just need to put /some/place/<arch> in > front of your path, then you don't need any wrappers. I don't like idea of fiddling with PATH inside automated build scripts. Of course, this would help with binutils tools. But now we have all our platform-specific logic inside Makefiles. I can just say make FOR=lnx to do native build and make FOR=w32 for mingw crossbuild. Yes, for some projects we also do make FOR=dj for DJGPP cross-build, but openssl is not one of these yet. Resetting CC, RUNLIB and AR variables seems to be much more harmless than changing PATH. This approach allows to treat different compilers for same target platform (say icc and gcc on Linux or MSVC and mingw32 gcc on Win32) same way as compilers for different target platforms. > If the idea is to use a single gcc compiler driver to automatically > invoke the right cross-compiler based on commandline args, I guess you > can go to the trouble of setting up all the pathnames that gcc expects, > but it seems like wasted effort to me. It's only useful if you're Main drawback of this approach is that you have to specify BOTH architecture AND version in the command-line explicitely, if your compilers for different architectures are different. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
