Mail Archives: djgpp-workers/1996/09/23/14:14:42
> > 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 true, the converter was not originally developed by me but
by Eberhard Mattes for use with EMX (which I guess does not support
COFF). The original converter was developed many many years ago
(probably 4-5 from memory) but only worked on small, simple source
files. When I originally found out about it (and that it would work
with DJGPP) I grabbed it and started trying to use it. Pretty soon I
found that many of the complex assembler files I had did not work
properly, so I started looking into fixing it. At the time I did not
know enough about OBJ file internals, and it took me about 3 years
to finally get around to fixing it (actually our tools also needed
some of the support that is present in DJGPP V2 but missing from V1
such as selector allocation etc which DPMI provides)! In the end I
sent my changes back to Eberhard and he added a bunch of other new
fixes and then we ended up where we are now.
> > 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.
If we can provide a command line switch to LD to solve the problem,
this would be the best short term solution. I am talking with Eberhard
about the complexities of converting the tool to COFF format (btw,
can someone point me to some docs on the COFF object file format?),
but this is going to be a long process to get completed.
Also remember that POV-Ray 3.0 (just released) comes with pre-built
libraries for parts of the product (mostly stuff that uses our
libraries, since the user may not have the required TASM assembler
to re-build the modules) and hence this will break with 2.01
immediately, which is what started this whole thread.
At the risk of breaking existing code and tools, what I would
suggest is if we can modify the LD linker to support A.OUT object
files for 2.01, and then we can look into converting the object
file converter in the future.
Regards,
+--------------------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+--------------------------------------------------------------------------+
| Kendall Bennett | Email: KendallB AT scitechsoft DOT com |
| Director of Engineering | Phone: (916) 894 8400 |
| SciTech Software, Inc. | Fax : (916) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+--------------------------------------------------------------------------+
- Raw text -