readme file for DRI2GNU.TTP

DRI2GNU is a simple DRI to GNU CC (that is, UNIX a.out format) object
converter.
I wrote this, because I use a different assembler than GAS, and don't
want to convert my sources to the totally different syntax of GAS.
I tested this not very much indeed, but it should work quite well.
(Note: I'm using this tool with PURE C and the PURE ASSEMBLER, so if
       you use different compilers/assemblers, it may be that this
       doesn't work correctly.)
Since this tool is a very quick (one day) hack without full
documentation (at least an a.out man page from a SUN and ATARI's ALN
(ATARI linker) doc, which isn't very thorough either), it's likely
for bugs to appear.

If you fall across some bugs, please mail me at
<Joerg.Hessdoerfer@EUROPA.rs.kp.dlr.de> (which I prefer) or at
<Hessdorf@sun.ph-cip.uni-koeln.de>

Please try the first address, but if you encounter problems with the
point before the @, use the 2nd. (Most E-mailers work, though :-)

Oh, yes, how to use it:

type <dri2gnu file1 ... >

DRI2GNU accepts only object files in DRI format as input, and will
complain otherwise. You can specify as many inputs as you like,
there are *NO* command-line options (rather un-UNIX-like, hu? ;-).

DRI2GNU will overwrite your original objects, and no error checking
other than a check whether the file could be opened is performed.
(This is so because objects can be re-created easily, or not?!?)
If you dislike this behaviour, feel free to change it, but don't
forget to read the file COPYING in any case!

Have fun, Joe

08.12.92:
   Fixed a bug that was due to misinterpretation of a.out string
   table format. Now sym-ld.ttp can link dri2gnu generated objects
   too.
   I experienced an unknown symbol format in some PASM objects,
   with type-code c0, but since these seem not to be global symbols
   (which means, they're not used for linking) one can rely on the
   fact that dri2gnu ignores them anyway. I didn't experience any
   problem with later usage of the generated objects.
