This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Rainer,> executables generated by testhello.sh on a native cygwin system.
I built a cygwin cross compiler using demo-cygwin.sh and crosstool-0.28-rc37, and then successfully ran the 4 test
One possibility is the version of cygwin1.dll that you are using on the target system, as I have heard that the executables will crash on older versions of cygwin. The version that I ran the executables on is: 1.5.11 (0.116.4.2) 2004-09-04 and Windows XP Pro.
The Cygwin stuff in the crosstoolchain and the Cygwin stuff in the runtime of course should be just the same in the ideal case ! If this case cannot be achieved, for instance when targeting to several runtime systems with different versions of Cygwin installed, then one could trust things being backwards compatible and using the oldest Cygwin stuff in those target systems in the crosstoolchain is the best choice.
If there is only one runtime, for instance the 1.5.11, then one uses its runtime stuff:
F:\gnu\cygwin>dir Volume in drive F is F_LEVY Volume Serial Number is 109F-0B76
01.12.2004 09:03 <DIR> . 01.12.2004 09:03 <DIR> .. 26.05.2004 01:07 1 181 032 cygwin-1.5.10-3.tar.bz2 05.09.2004 02:18 1 179 700 cygwin-1.5.11-1.tar.bz2 <---- ! 10.11.2004 13:36 1 187 032 cygwin-1.5.12-1.tar.bz2 31.01.2004 00:34 1 235 068 cygwin-1.5.7-1.tar.bz2 16.03.2004 04:20 1 247 310 cygwin-1.5.8-1.tar.bz2 19.03.2004 03:06 1 244 314 cygwin-1.5.9-1.tar.bz2 6 File(s) 7 274 456 bytes 2 Dir(s) 9 297 346 560 bytes free
and a w32api package suitable with this in the produced crosstoolchain for Cygwin. When these released packages should be thoroughly regression tested etc. by the Cygwin maintainers, it is quite insane to try to self-compile them again :
today i successfully built a new toolchain, with crosstool-0.28-rc37 using:
binutils-2.15.tar.bz2
cygwin-1.5.10-3-src.tar.bz2
The 'cygwin-1.5.10-3.tar.bz2' is available, so where is the beef here? Does someone really believe being much better than the Cygwin maintainers in producing the 'cygwin-1.5.10-3' runtimes? A little more humble attitude please...
Generally using this old runtime sounds good but not recompiling it before being absolute sure about the GCC and binutils working as they should. If GCC or binutils produce bad code, also the produced cygwin1.dll etc. are bad...
gcc-3.3.2.tar.bz2
Again the Cygwin/Windoze target may require still not accepted patches, the MinGW alternative (which is my preferred runtime for Windoze) has :
07.01.2005 11:46 92 237 gcc-3.2.3-20030504-1-src.diff.gz 07.01.2005 11:57 73 048 gcc-3.3.1-20030804-1-src.diff.gz 17.06.2004 08:58 122 692 gcc-3.3.3-20040217-1-src.diff.gz 07.01.2005 11:55 104 532 gcc-3.4.2-20040916-1-src.diff.gz
the build process creates cygwin1.dll in: $ ls -l /opt/crosstool/i686-pc-cygwin/gcc-3.3.2-/bin/cygwin1.dll -rwxr-xr-x 1 raho develop 7507764 Jan 13 09:23 /opt/crosstool/i686-pc-cygwin/gcc-3.3.2-/bin/cygwin1.dll
this is a real big dll, compared to the one installed by the cygwin setup program:
$ ls -l /bin/cygwin1.dll
-rwxr-x---+ 1 raho develop 1153417 May 26 2004 /bin/cygwin1.dll
is this correct?
My advice would be to build the crosstoolchain totally normally using the prebuilt Cygwin and w32api runtime headers and libraries, and use the patched original Cygwin binutils and GCC sources. AFAIK the Cygwin releases are still produced on Red Hat Linux, so the Linux host should work as the $build system with the Cygwin sources. After using the GCC and binutils with the original Cygwin headers and libraries and being sure the GCC and binutils work for producing new code for Cygwin, maybe then one could try to rebuild the already built libraries. But if being humble, one usually doesn't try this...
the cross-compiled testprogram still crashes under native cygwin ;-(
It shouldn't hurt to produce the crosstoolchain "normally", like any other cross-GCC for a proprietary/custom target. Just forget that the Cygwin runtime sources are available and use the prebuilt runtimes... For the proprietary targets the runtime library sources are never available and one should know how to produce crosstools for these, or how?
I myself have never cared to rebuild the Cygwin and MinGW runtimes, only added more to them like local support for producing stuff for Win32s (haven't updated this though, my 'working' Win3.1x/Win32s supporting tools are based on MinGW runtimes from 1999-2000) -- a hundred million flies weren't wrong, they believed DOS/Win3.1x being the best opsys in the 1990's, not Novell's $165 UnixWare or the almost no-cost Linux... Ok, what the Cygnus/Red Hat people claimed to be "impossible", was a challenge...
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |