From:	khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject:	Re: Mingw32-ecgs DLL cann't load, cross-compile can, same tools
15 Oct 1998 13:16:02 -0700 :
Message-ID:	<9810142006.AA11337.cygnus.gnu-win32@modi.xraylith.wisc.edu>
References:	<K3ZydZAUpPJ2Ew6N AT dsteele DOT demon DOT co DOT uk>
To:	Douglas Steele <Douglas AT dsteele DOT demon DOT co DOT uk>
Cc:	gnu-win32 AT cygnus DOT com

Douglas Steele <dsteele DOT demon DOT co DOT uk AT dsteele DOT demon DOT co DOT uk> writes:
> 
> I have a small standard test dll program (from ftp://sirio.stat.unipd.it
> /pub/dltest ).  The cross-compiled version works perfectly.  The
> directly compiled version (using identical tools) is unable to load.
> 
> The dll failure to load on the small test program illustrates a dll
> failure to load problem with the R statistical system reported by a
> number of other users on Win95.
> 
> The dll version which fails to load has large blocks of junk string data
> which are set to \0 in the cross-compiled version.  (This is the most
> noticeable difference on an od -c then diff).  Note though that the
> object files are identical, so that the discrepancies are occurring
> after object file creation.

[ ... ]

These are quite possibly due to bugs ("features" in MS parlance ;-) in
W95 CRTDLL runtime routines; fseek on W95 for example doesn't zero out 
the storage when you seek past the end of file, while it does do the
right/expected thing on WinNT (and of course when built cross on a unix
box).

As soon as I get a chance, I want to build version of binutils using a
replacement fseek and see if that's what's happening. 

Any other routines with such behaviour that may be causing this?

Regards,
Mumit

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -