Poll of the week: main OS and compiler

[Jacob Carlborg]

On 2012-03-08 16:12, Manu wrote:
> On 8 March 2012 16:41, Jacob Carlborg <doob at me.com <mailto:doob at me.com>>
> wrote:
>
>     On 2012-03-08 10:12, Manu wrote:
>
>         On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg at gmx.com
>         <mailto:jmdavisProg at gmx.com>
>         <mailto:jmdavisProg at gmx.com <mailto:jmdavisProg at gmx.com>>> 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.

Yes, the runtime used by the Microsoft compiler.

> 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?

Jonathan explained this very good.

-- 
/Jacob Carlborg