On 8 March 2012 16:41, Jacob Carlborg <[email protected]> wrote: > On 2012-03-08 10:12, Manu wrote: > >> On 8 March 2012 00:21, Jonathan M Davis <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wednesday, March 07, 2012 23:07:11 Mars wrote: >> > On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote: >> > > Personally, I just want to be able to link like a normal >> > > windows developer. >> > > My code is C/C++, built with VC, and I want to link my D app >> > > against those >> > > libs using the VC linker, and debug with Visual Studio. This is >> > > the >> > > workflow I think the vast majority of Windows devs will expect, >> > > and it >> > > sounds simple enough. This is the only thing standing between >> > > me using D >> > > for any major projects, and just experimenting with the >> > > language for >> > > evaluation, or just academic interest. >> > > 64bit is far less important to me personally, VisualC linker >> > > compatibility >> > > is the big one. I just want to link against my C code without >> > > jumping >> > > through lots of hoops. >> > >> > That's exactly my problem... and although I love D, these hurdles >> > made me take a step back, to C++, while I wait for this to >> > change, so I can finally use D efficiently. >> > >> > I'm sure this isn't a trivial task, but the problematic isn't new >> > after all. Why hasn't it been addressed yet? In my eyes this >> > should be a top priority, to make it easier for new users to get >> > into D. Till this poll I actually believed the problem was that D >> > isn't used much by Windows users. >> >> I don' think that Walter really views it as much of a problem - or >> if he does, >> he didn't used to. Remember that he's used to an environment where >> he doesn't >> use Visual Studio or Microsoft's C++ compiler. And his customers use >> dmc just >> like he does (since they're his customers), so many of the people >> that he >> interacts with in the C/C++ world are not necessarily particularly >> Microsoft- >> centric on Windows. >> >> Add to that the enormous task that it is to actually make dmd work >> with COFF >> or 64-bit or anything of the sort on Windows, and it's no wonder that >> it >> hasn't happened yet. >> >> To be fair, there are plenty of other things that have needed to be >> done, and >> what we have for Windows does work, even if it's suboptimal. So, >> it's not all >> that unreasonable that the issue would be put off as long as it has >> been. And >> Walter _has_ been slowing working on porting optlink to C (the fact >> that it's >> written in assembly makes it really fast but hard to maintain and >> change), >> which would make it possible to then start porting stuff to 64-bit and >> considering COFF and stuff like that. >> >> >> Is it possible to just fix the compiler to output COFF objects *without* >> touching optlink at all? >> I'm not interested in using optlink with this feature, I intend to link >> with Visual Studio, that's the whole point. So ignoring optlink, that's >> a major slice of work taken out of the equation... >> Maybe it would be nice to support optlink in future, but it seems the >> priority is backwards. >> > > DMD would need to be compatible with the Microsoft linker and runtime as > well, that is, except from outputting object file in the correct format.
By 'runtime' you mean the crt? I don't think that'll be a major headache. Probably just a few subtle differences to deal with. A nice side effect would be that all those horrid OMF conversions of MS libs bundled with D wouldn't be necessary. And what else affects linker compatibility other than object format and mangling convention? How is DMD actually affected by any of this other than object format? Name mangling?
