Walter Bright Wrote: > Optlink is written entirely in rather impenetrable assembler code, and > is resistant to understanding and modification. Hence, over the last few > months I've been very slowly converting it to C, function by function. > > One might ask, why not convert it to D? The answer is that I don't have > a good test suite for optlink, so I have to be very very careful to not > make a mistake in the translation. That means do one function at a time, > rebuild, and retest, which means the compiled C code has to match the > segment, naming and calling conventions used in optlink. I made a custom > version of the dmc compiler to do this. Also, C can be made to work > without any runtime library support at all, and since optlink does not > use the C runtime library, this is useful. > > Once it is in C and working, it will be trivial to translate it to D and > start rewriting it. > > Anyhow, during this process I stumbled upon what the problem was. > Optlink was apparently trying to account for some Borland obscure > extension to the OMF. Remove this, and it works, although presumably it > will no longer link Borland object files (who cares!). > > The fix will go out in the next update, if you need it sooner please > email me.
Why not changing object format instead and using format acceptable by the linker from MinGW suit? That could free you from rewriting the linker in C, then in D and then maintaining it. Are there any difficulties (technical or even licensing)?
