From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9609212320.AA14385@clio.rice.edu>
Subject: Re: [KendallB AT scitechsoft DOT com: (Fwd) PoV-Ray compiling with DJGPP2.01]
To: dj AT delorie DOT com (DJ Delorie)
Date: Sat, 21 Sep 1996 18:20:07 -0600 (CDT)
Cc: djgpp-workers AT delorie DOT com, kendallb AT scitechsoft DOT com
In-Reply-To: <199609212247.SAA16086@delorie.com> from "DJ Delorie" at Sep 21, 96 06:47:35 pm
Content-Type: text
Content-Length: 2112      

> So far, nearly all the V1 code breaks because of these.  I haven't
> heard anyone say "but *my* V1 library works without recompiling!"

Okay - I'll say it - I have several numerical subroutine libraries compiled
with V1 and most worked fine (especially with ld 2.4).  Time to restore
source, recompile (with newer compiler... probably faster anyway...)
probably less than a couple of hours.  But I didn't have to... even though
I'm pretty sure some were compiled under V1.08.

Most V1.x library problems will be caused by using V1.10 or newer libs 
anyway - which are COFF - so this change doesn't address that issue at all.

> No, but it was developed long after djgpp switched to COFF.  It should
> have been COFF from the start.

It's actually an EMX tool - which is still using a.out - so you burn
the bridges for sharing tools like this one.  This tool was not developed
specifically for DJGPP.

> This is uncalled for.  There's a lot in V1 that we no longer support
> because it's not appropriate to support it.  We can't be 100%
> backwards compatible.  Every time we drop support for something,
> someone somewhere will complain.  We don't still support 0xd0000000,
> do we?  That was a *popular* one, too.

If there was a way to support 0xd0000000 under DPMI I would have done it.
This is a configuration switch to provide support for something still used.
I don't understand what providing a.out support breaks, but I do see several
things removing it breaks.  That's my point - it seems like in the hurry to
get 2.01 out the door, or provide some new ld feature it's OK to remove
features?

> Let Kendall decide if they can or can't make the changes to support
> COFF in their converter.  If they find it too difficult, and that
> difficulty combined with the popularity of their package warrants
> supporting an object format that hasn't been used by djgpp for years
> (4? 5?), we'll revisit the issue.

It's not a crisis - he can always provide an alternate ld (as is currently
done to work around a broken ld).  But I doubt Kendall wants to write a tool
from scratch just to support this change.