From:	martinm AT sps1 DOT phys DOT vt DOT edu (Michael B. Martin)
Subject:	Re: float problem ... and other DJGPP install problems
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Date:	Fri, 29 Jul 1994 11:00:30 -0400 (EDT)

---------------------- Begin Reference -----------------
  Hello, 

  I have trouble reading binary floating point data (4bytes/value) from a
  file generated on a sun/unix into my code compiled with djgpp.

[text deleted]
---------------------- End Reference -------------------

Well, based on your description, it sounds like your problem is the byte
ordering.  It is my understanding that all Sun systems use big-endian
CPUs, so the number 0x12345678 is stored as "12 34 56 78" on disk.  On all
80x86 CPUs (which are little-endian), the same number would be stored as
"78 56 34 12" on disk.  The only way I know of getting around this is to write
a routine to read in four bytes and reverse the order manually.  I have
written a small set of routines to do this sort of thing for my own code.  I
could send it to you if you like.



Now, I have some problems of my own.  After having not used djgpp for several
months (at least), I decided to give it a try again (especially since I am
also using Linux more now).  I grabbed the 1.11 distribution from oakland and
installed it using the directions (including the five maint. releases).  I
tried to compile the first "test" file (t01.c), and everything worked fine
until it got to the linker.  ld.exe spit out the following message and died:

c:/djgpp/lib/crt0.o: malformed input file (not rel or archive)

I assume this means that it doesn't think crt0.o is a proper object file.
I tried reverting to the crt0.o in djdev111.zip (and dj111m3.zip), and it
didn't change anything.  Could someone tell me what wrong here?  I am
wondering if this is a known problem, or if my system does something (really)
strange to mess things up.  Anyway, I have fallen back to the 1.10 dist.,
and now (of course) I am having some minor (but annoying) problems of another
kind.  Make.exe (from mak369bn.zip) doesn't seem to want to work with 1.10.
Instead of running the makefile like it should (and does with 1.11m?), it
prints out the same message that go32 does when run without arguments.  Well,
I thought I'd give Borland make (from Borland C++ 3.1) a try, but that still
doesn't work right.  Using Borland's make, it seems to work fine, but the
compiler just keeps going, constantly accessing the hard disk (for a few
minutes at least), until I reboot (the only way to stop it).  I've used the -v
option, and it gets through cpp.exe just fine, but "hangs" on the actual
compile.  I haven't actually let it run a very long time yet just to see if
it really is working, just VERY slowly.  Has anyone else had this problem
before?

Well, this is long enough.  Thanks in advance for any help!

-Michael (martinm AT sps1 DOT phys DOT vt DOT edu)

(Eagerly awaiting 1.12 and cbgrx 1.04 :)

- Raw text -