On 3/7/2013 8:16 PM, Brad Roberts wrote:
> 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 like being able to provide a completely free D toolchain for win32.

On Friday, 8 March 2013 at 07:17:24 UTC, Walter Bright wrote:
> On 3/7/2013 8:16 PM, Brad Roberts wrote:
>> 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 like being able to provide a completely free D toolchain for win32.

The express edition of Visual Studio should be enough to provide e.g. the linker.
http://www.microsoft.com/visualstudio/eng/downloads#d-express-windows-desktop
It is free. However you do need to register after 30 days.

On 2013-03-08 04:41, Walter Bright wrote:

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

If we have our own linker for every supported platform and format I pretty sure that we can take advantage of that and come up with features not possible using other linkers.

For example, storing .di files directly in the object file. This has also been suggested before.

-- 
/Jacob Carlborg

08-Mar-2013 00:15, Andrej Mitrovic пишет:
> On Thursday, 7 March 2013 at 20:01:58 UTC, Walter Bright wrote:
>> What we *can* do with Optlink is fix the occasional bug that crops up
>> in it.
>
> I hope so. :)
>
> On Thursday, 7 March 2013 at 20:01:58 UTC, Walter Bright wrote:
>> I also believe that even if Optlink were completely converted to C, it
>> will still be intractably difficult to refactor it to do things like
>> support other object file formats.
>
> I really wish Unilink[1] was open-source.

Same here. Maybe we should try and convince him to share it with some OpenSource license?

> It's apparently a student
> project, and it's closed source but freeware. It works with OMF but can
> also link OMF and COFF objects together, which is a boon for win32
> programmers who don't want to go through OBJCONV (object file
> conversion, doesn't always work) or COFF2OMF (import libs). It also has
> pretty good error messages.
>
> Of course there's no telling how big its test-suite is. It's fairly easy
> to set up though[2].
>
> [1] ftp://ftp.styx.cabel.net/pub/UniLink/
> [2]
> http://forum.dlang.org/thread/jbvugp$8l3$1@digitalmars.com#post-mailman.1414.1323538292.24802.digitalmars-d:40puremagic.com
>
>
> On Thursday, 7 March 2013 at 20:01:58 UTC, Walter Bright wrote:
>> This is why I had started a new linker project.
>
> Interesting. But if it's made behind-the-scenes with no input or work
> from the community I won't be holding my hopes up too much, I know you
> have very limited time for side-projects like that.


-- 
Dmitry Olshansky

08-Mar-2013 12:50, Jacob Carlborg пишет:
> On 2013-03-08 04:41, Walter Bright wrote:
>
>> 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.
>
> If we have our own linker for every supported platform and format I
> pretty sure that we can take advantage of that and come up with features
> not possible using other linkers.

Yes, along with storing meta-data such as pure, nothrow etc. Mangling does it but in a such a backward way...
But it would always have to maintain backwards compatibility or simple conversion to this format.

> For example, storing .di files directly in the object file. This has
> also been suggested before.
>


-- 
Dmitry Olshansky

On 3/8/2013 12:50 AM, Jacob Carlborg wrote:
> If we have our own linker for every supported platform and format I pretty sure
> that we can take advantage of that and come up with features not possible using
> other linkers.
>
> For example, storing .di files directly in the object file. This has also been
> suggested before.


Sure, but who is going to do the work?

BTW, we did come up with our librarian (it's built in to dmd) and it works great - enabling simple, smooth handling of libraries in a way that no other similar language does. Notice, though, there are 4 completely distinct code bases to support it, for the 4 main platforms. The librarian is a simple program, but linkers are much more complex.

On 2013-03-08 09:58, Walter Bright wrote:

> Sure, but who is going to do the work?

Anyone that's interested in doing the work. But we don't have to invest all our time doing it. Daniel Murphy seems to be working on a linker, so apparently there is at least some interest.

> BTW, we did come up with our librarian (it's built in to dmd) and it
> works great - enabling simple, smooth handling of libraries in a way
> that no other similar language does. Notice, though, there are 4
> completely distinct code bases to support it, for the 4 main platforms.
> The librarian is a simple program, but linkers are much more complex.

Yeah, I didn't say it was going to be easy.

-- 
/Jacob Carlborg

On 08.03.2013 08:25, Rikki Cattermole wrote:
> On Friday, 8 March 2013 at 07:17:24 UTC, Walter Bright wrote:
>> On 3/7/2013 8:16 PM, Brad Roberts wrote:
>>> 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 like being able to provide a completely free D toolchain for win32.
>
> The express edition of Visual Studio should be enough to provide e.g.
> the linker.
> http://www.microsoft.com/visualstudio/eng/downloads#d-express-windows-desktop
>
> It is free. However you do need to register after 30 days.

There are also C++ compiler and linker in the Windows 7 SDK that you can download and install without registering (http://www.microsoft.com/en-us/download/details.aspx?id=8442).

It might be fun, but I think that building your own COFF capable linker will be a huge undertaking if you want to link against C/C++ code built with the MS compiler without stripping a whole lot of information (debug information, FPO records, etc).

On Friday, 8 March 2013 at 05:29:14 UTC, Rikki Cattermole wrote:
> 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.

I'd love to have an option like that. Win32 is at the very least going to be a target for many years to come (for some also a development platform) and the OPTLINK/OMF business is a real impediment.

On 3/8/13, Walter Bright <newshound2@digitalmars.com> wrote:
> On 3/7/2013 8:16 PM, Brad Roberts wrote:
>> 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 like being able to provide a completely free D toolchain for win32.

s/for win32/./

:)

Honestly D has huge potential for tools like compilers/linkers/etc. They're the types of programs where you practically know all your requirements at compile-time, so e.g. generics come into play really nicely.

We should keep the idea of having a free D toolchain for all OSes in the back of our heads, even if we don't work on it any time soon.