Unilink - alternative linker for win32/64, DMD OMF extensions?

After hitting some troubles with optlink in the past (though my problems
got solved others may be not)
I was in constant search for alternatives.
The good news:
there *do* happen to be very versatile linker for windows able to
produce  32/64bit PE, that supports OMF format and so on. Another cool
thing that has is so called mix-mode linking i.e. linking objects
produced by different compilers with different RTLs (tricky but might
worth the effort).
Link to ftp with docs and binary: ftp://ftp.styx.cabel.net/pub/UniLink/
According to author it does fully support DMC++ along with a huge pack
of other C++ compilers.

Now the bad news:
it doesn't quite work with DMD for the moment. It's able to link test.d,
but fails to link test2.d. (see attach) Stating that the resulting OMF
is invalid. I asked the developer about it,  his reply:
/reply

DM is in list of supported compilers (with DM C extensions). But D
extension in sample is suspicious. There it attempt to define "select
any" comdat that referenced to TLS-type segment. This is similar to common
backend error. Another possibility is that it is an D "extension". But
we don't possess documentation of D object format extensions and only
can gess what it is.

If the D becomes common used language we can "examine" its new
features and take in into consideration. But... Maybe is's easier to
contact with D developer and ask for new features in objects.
/end reply

QUESTION
--->>>
So here I am asking what kind of OMF extensions DMD uses, and what's difference between test.d and test2.d in terms of object file output?
<<<---

Any hints on where to look for them are also welcome.
If they are minor then we can convince the developer
and have 64bit linker to experiment with on windows.

NOTES

I used dmd 2.051, though with 2.050 it's the same issue;
command line:
dmd -c<xxx>.d

For those interested in experimenting with unilink themselves,
use the following config (ulink.cfg) adjusting the path to dmd as needed:
-zkernel32;advapi32;user32;wsock32;shell32;snn.lib
-LC:\dmd2\windows\lib
-Go

Then linking is just: ulink <xxx>.obj

-- 
Dmitry Olshansky

Yeah I can reproduce the same thing as you have. I did manage to convert an OMF to COFF file format, and link it with GCC (MinGW). See my thread here: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=127079 I have yet to try it on more complex examples though. Give it a try and let me know if it works? :)

On 23.01.2011 20:43, Andrej Mitrovic wrote: > Yeah I can reproduce the same thing as you have. > > I did manage to convert an OMF to COFF file format, and link it with > GCC (MinGW). See my thread here: > > http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=127079 > > I have yet to try it on more complex examples though. Give it a try > and let me know if it works? :) Well after a pass through omf2d, the ulink says about the resulting obj: Fatal: Entry point must be specified So, yes it strips something, yet it's no longer an invalid OMF ;) Anyhow after jumping though some hoops with objconv I got ld to linktime, but it gets a pack of unresolved externals from D's runtime/phobos and I don't think converting them all is wise idea. -- Dmitry Olshansky

Dmitry Olshansky wrote: > If the D becomes common used language we can "examine" its new > features and take in into consideration. But... Maybe is's easier to > contact with D developer and ask for new features in objects. If the author wants to email me with any specific questions, I'd be happy to help him.

On 23.01.2011 23:55, Walter Bright wrote: > Dmitry Olshansky wrote: >> If the D becomes common used language we can "examine" its new >> features and take in into consideration. But... Maybe is's easier to >> contact with D developer and ask for new features in objects. > > If the author wants to email me with any specific questions, I'd be happy to help him. Yeah, that's the problem, I suppose he would not bother with D support himself unless someone proves it's usefulness. It's more like we need a little help not the other way around. Well, anyway I can mail him and hope that he will do it just out of curiosity, what's yours relevant email then? May I just as well tell him that you are interested in it or anything? -- Dmitry Olshansky

Dmitry Olshansky wrote: > On 23.01.2011 23:55, Walter Bright wrote: >> Dmitry Olshansky wrote: >>> If the D becomes common used language we can "examine" its new >>> features and take in into consideration. But... Maybe is's easier to >>> contact with D developer and ask for new features in objects. >> >> If the author wants to email me with any specific questions, I'd be happy to help him. > Yeah, that's the problem, I suppose he would not bother with D support himself unless someone proves it's usefulness. It's more like we need a little help not the other way around. > > Well, anyway I can mail him and hope that he will do it just out of curiosity, what's yours relevant email then? > May I just as well tell him that you are interested in it or anything? > First off, there are no D extensions to the OMF. There was an extension added around 1993 or so to support long identifier names. There were also a couple extensions to the codeview debug format, which are documented in the ABI. My offer is if there is something specific about the OMF files generated that I can explain to him, I'd be happy to do so. My mail is walter followed by digitalmars.com.

Walter Bright Wrote: > Dmitry Olshansky wrote: > > Well, anyway I can mail him and hope that he will do it just out of > > curiosity, what's yours relevant email then? > > May I just as well tell him that you are interested in it or anything? > > > > My offer is if there is something specific about the OMF files generated that I can explain to him, I'd be happy to do so. My mail is walter followed by digitalmars.com. Any news here?

Forums