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]

Re: c++ exceptions in shared library results in crash


Steve Papacharalambous wrote:

Hi Rainer,

I built a cygwin cross compiler using demo-cygwin.sh and crosstool-0.28-rc37, and then successfully ran the 4 test
> executables generated by testhello.sh on a native cygwin system.

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

Directory of F:\gnu\cygwin

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

Most probably quite a lot Cygwin-specific patches are required...


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

for all kind of Windoze-specific things, for $host and $target roles...

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]