On 2/12/11, Walter Bright <newshound2@digitalmars.com> wrote:
> Andrej Mitrovic wrote:
>> Great, from one closed-source linker to another.
>
> Making optlink open source won't make any difference. Few are skilled at asm anymore, and likely none of them would want to work on optlink for free.
>

Ok, but what about your upcoming C version?

Don't get me wrong, I appreciate that we even have a linker! But it's kind of sad when one of the most active D developers quits because of linker issues.

> Making optlink open source won't make any difference. Few are skilled at asm anymore, and likely none of them would want to work on optlink for free.

That's true. But the real problem is not optlink. Optlink is a very good linker.

The problem is OMF. 11 years ago OMF was a good choice. But not anymore.

I know you are a competent (probably very competent) compiler writer. You modified D on linux, so it produce ELF. How much time would that take to modify DMD so it produce COFF ? Given all the bad publicity OMF gives to D, it should be viewed as a good choice.

There are many (not much), but there are open source linkers. Of course ld is not as fast as optlink, but it's good. And there is a faster version made by the project Ultimate++ IDE.

Going to COFF would have a lot of advantages for everybody and for D.

Do you agree ?

Andrej Mitrovic Wrote:

> On 2/12/11, Walter Bright <newshound2@digitalmars.com> wrote:
> > Andrej Mitrovic wrote:
> >> Great, from one closed-source linker to another.
> >
> > Making optlink open source won't make any difference. Few are skilled at asm anymore, and likely none of them would want to work on optlink for free.
> >
> 
> Ok, but what about your upcoming C version?
> 
> Don't get me wrong, I appreciate that we even have a linker! But it's kind of sad when one of the most active D developers quits because of linker issues.

We should rename Optlink to Vuvulink, it's the vuvuzela of D's world. We can't seriously use D with any commercial technologies since the code isn't binary compatible. This is getting ridiculous. 12 years of fail. We could even pay to get a proper linker. But how much would it cost? Around $200000 - $500000. That's too much. We could outsource our whole software development at that price and focus on profits.

Akakima wrote:
>> Making optlink open source won't make any difference. Few are skilled at asm anymore, and likely none of them would want to work on optlink for free.
> 
> That's true. But the real problem is not optlink. Optlink is a very good linker.
> 
> The problem is OMF. 11 years ago OMF was a good choice. But not anymore.
> 
> I know you are a competent (probably very competent) compiler writer. You modified D on linux, so it produce ELF. How much time would that take to modify DMD so it produce COFF ? Given all the bad publicity OMF gives to D, it should be viewed as a good choice.
> 
> There are many (not much), but there are open source linkers. Of course ld is not as fast as optlink, but it's good. And there is a faster version made by the project Ultimate++ IDE.
> 
> Going to COFF would have a lot of advantages for everybody and for D.
> 
> Do you agree ?

Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files.

Walter:

> Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files.

What about linking with MinGW (GCC 4.5+) object files?

Bye,
bearophile

On Saturday 12 February 2011 17:09:36 Walter Bright wrote:
> Akakima wrote:
> >> Making optlink open source won't make any difference. Few are skilled at asm anymore, and likely none of them would want to work on optlink for free.
> > 
> > That's true. But the real problem is not optlink. Optlink is a very good linker.
> > 
> > The problem is OMF. 11 years ago OMF was a good choice. But not anymore.
> > 
> > I know you are a competent (probably very competent) compiler writer. You modified D on linux, so it produce ELF. How much time would that take to modify DMD so it produce COFF ? Given all the bad publicity OMF gives to D, it should be viewed as a good choice.
> > 
> > There are many (not much), but there are open source linkers. Of course ld is not as fast as optlink, but it's good. And there is a faster version made by the project Ultimate++ IDE.
> > 
> > Going to COFF would have a lot of advantages for everybody and for D.
> > 
> > Do you agree ?
> 
> Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files.

That's a problem for some code and pretty much an absolute necessity for other code. Any project that I'd do at work would _have_ to use Microsoft's runtime library. In the long run, we really do need a solution which is compatible with Microsoft's compiler. Without that, there are a lot of programmers who just won't be able to use D in any project which would be using C or C++ code, and not being able to use any C or C++ code in D can be a major problem - especially if you're trying to use D with an existing code base.

So, I really don't know what the best way to handle all of this is, and I really don't know all that much about linkers, but the fact that you can't link D code with C code generated by Microsoft's compiler is crippling for Windows development.

- Jonathan M Davis

>
> Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files.

I found some doc there:

  http://pierrelib.pagesperso-orange.fr/exec_formats/index.html

Microsoft Symbol and Type Information
By TIS / Microsoft. Entry added 12/28/2004.
Keywords: ms, symbol, type, info
File: MS_Symbol_Type_v1.0.pdf
« This document describes Microsoft Symbol and Type Information, a debugging
information format fromMicrosoft Corporation for the 32-bit Windows
environment. »

There is also some doc on the MSDN CD that comes with Visual C++ 6.0.

Akakima wrote:
>> Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files.
> 
> I found some doc there:
> 
>   http://pierrelib.pagesperso-orange.fr/exec_formats/index.html
> 
> Microsoft Symbol and Type Information
> By TIS / Microsoft. Entry added 12/28/2004.
> Keywords: ms, symbol, type, info
> File: MS_Symbol_Type_v1.0.pdf
> « This document describes Microsoft Symbol and Type Information, a debugging information format fromMicrosoft Corporation for the 32-bit Windows environment. »


That document describes the Codeview symbol debug format, which Microsoft abandoned 15 years ago in favor of a proprietary format.

Dmd generates that older format :-)

Walter Bright wrote:

> Akakima wrote:
>>> Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files.
>> 
>> I found some doc there:
>> 
>>   http://pierrelib.pagesperso-orange.fr/exec_formats/index.html
>> 
>> Microsoft Symbol and Type Information
>> By TIS / Microsoft. Entry added 12/28/2004.
>> Keywords: ms, symbol, type, info
>> File: MS_Symbol_Type_v1.0.pdf
>> « This document describes Microsoft Symbol and Type Information, a
>> debugging information format fromMicrosoft Corporation for the 32-bit
>> Windows environment. »
> 
> 
> That document describes the Codeview symbol debug format, which Microsoft abandoned 15 years ago in favor of a proprietary format.
> 
> Dmd generates that older format :-)

Are you going to do Elf? With optlink in D? (Does that even make sense?)

Lutger Blijdestijn wrote:
> Walter Bright wrote:
> 
>> Akakima wrote:
>>>> Changing the object module format is not sufficient. The symbolic debug
>>>> info would have to be changed (and Microsoft's is undocumented) and then
>>>> there's the dependency on Microsoft's C runtime library if linking with
>>>> VC generated object files.
>>> I found some doc there:
>>>
>>>   http://pierrelib.pagesperso-orange.fr/exec_formats/index.html
>>>
>>> Microsoft Symbol and Type Information
>>> By TIS / Microsoft. Entry added 12/28/2004.
>>> Keywords: ms, symbol, type, info
>>> File: MS_Symbol_Type_v1.0.pdf
>>> « This document describes Microsoft Symbol and Type Information, a
>>> debugging information format fromMicrosoft Corporation for the 32-bit
>>> Windows environment. »
>>
>> That document describes the Codeview symbol debug format, which Microsoft
>> abandoned 15 years ago in favor of a proprietary format.
>>
>> Dmd generates that older format :-)
> 
> Are you going to do Elf? With optlink in D? (Does that even make sense?)

Elf is not a symbolic debug format. It is possible to use Codeview with Elf.

In any case, such decisions will have to revolve around the availability of things like debuggers.