Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<42EFC5F3.9080708@familiehaase.de>
Date:	Tue, 02 Aug 2005 21:13:55 +0200
From:	"Gerrit P. Haase" <gerrit AT familiehaase DOT de>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728
MIME-Version:	1.0
To:	Stein Somers <ssomers AT opnet DOT com>
CC:	cygwin AT cygwin DOT com
Subject:	Re: bug report: abort in g++ 3.4.4 generated DLL & client
References:	<42EFA9DC DOT 7030800 AT opnet DOT com>
In-Reply-To:	<42EFA9DC.7030800@opnet.com>
X-IsSubscribed:	yes

Stein Somers wrote:

> Below is minimalistic textbook "how to generate a DLL" code, brought to 
> flavour by a grain of C++ salt. However it abort if compiled and run 
> with the latest gcc 3.4.4.1 and binutils 20050610-1 releases (as opposed 
> to the alternative 3.3.3.3, and I suspect any other version this century).
> 
> When run from a bash script, the compiled executable aborts with:
>    2400 Aborted                 (core dumped)
> When run from within a bash shell, that's a mere:
>    Aborted (core dumped)
> When run from a DOS prompt, it aborts silently.
> 
> It coredumps consistently on 3 out of 4 PCs tested (two of which have 
> identical hardware, and one which has entirely different components), 
> running either Windows XP, Windows 2000 SP4  or an almost immaculate 
> Windows 2000 SP3 (for which cygcheck output is listed). However, it did 
> not abort on a machine when that had the same gcc-3.4.4.1 installed, but 
> a slightly older binutils. The code compiled at that moment on that 
> machine does abort on the others. If you wonder what version of binutils 
> that might have been, so do I... It's no the 20050608-2 alternative 
> offered by the package selector.


I'm confused.  Do you mean the code compiled on the sane machine, where
the binary runs ok when compiled with the older binutils, is crashing
when simply copying the executable to another machine?  Isn't it a
cygwin problem then and not an issue which version of gcc or binutils
is used?

I get the same result when running a binary compiled with gcc-3.4.4 /
binutils-20050608-2 / cygwin-1.5.17, here it is running fine, running
the idebntical executable at another box with cygwin-1.5.18 gives me
the crash.


> binutils             20050610-1
> gcc                  3.4.4-1

When compiled on this machine, what is the cygwin version and what is
the cygwin version on the box where it works ok?



Gerrit
-- 
=^..^=

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -