On Friday, 8 March 2013 at 04:17:03 UTC, Brad Roberts wrote:
On 3/7/2013 7:41 PM, Walter Bright wrote:
On 3/7/2013 7:27 PM, Daniel Murphy wrote:
"Walter Bright" <[email protected]> wrote in message
news:[email protected]...
On 3/7/2013 7:09 PM, Daniel Murphy wrote:
That's correct. However, it'll be much more maintainable,
I don't know how much redesign you're planning, but I can't
imagine it ever
being as maintainable as a pure d codebase. A less
stable/complete linker
that attracts more contributors should overtake a more stable
linker with
only a couple of developers that grok it.
That's true, but we don't have that other linker yet.
The other thing is, we just don't have a need for our own
linker for any platform other than win32. So what's the cost
benefit moving forward? I think it's easier to just fix
optlink's bugs.
I don't want to discourage people from trying to come up with
a replacement linker for win32 written in D. I think that
is a great project. But while a linker is a conceptually
simple program, the awful file formats involved make it
unnecessarily difficult and there are simply a lot of details
and other things one has to do.
Like I said before, it'll take a sustained and determined
effort to come up with a viable replacement for optlink.
Personally, even though I don't use win32, I believe that
moving it over to use the VS toolchain and runtime is the
right path forward.
I've actually modified dmd's frontend to support using the VS
tool chain for linking 32 bit executables. But I didn't
understand the backend to seperate the 32bit binary generation vs
64bit. I believe it shouldn't be too much. But I really don't
understand it so if anyone is willing to help on this.
I haven't broken 64bit generation as far as I know. Because I
added a cli argument (-msvc) which is enabled for -m64
automatically on Windows.
