Leandro Lucarella wrote:
> grauzone, el  4 de noviembre a las 17:23 me escribiste:
>> Walter Bright wrote:
>>> Anyhow, during this process I stumbled upon what the problem was.
>>> Optlink was apparently trying to account for some Borland obscure
>>> extension to the OMF. Remove this, and it works, although
>>> presumably it will no longer link Borland object files (who
>>> cares!).
>> And during all that time, GNU ld worked just fine, completely
>> without bugs! I had to add hacks to my code to make it linkable on
>> Windows.
>>
>> And no, GNU ld is not too slow.
> 
> And if you really find it slow, GNU Gold (done by Google) is *much*
> faster.

Last I heard from it, Gold (or dmd?) had some bugs which made it unusable with dmd. Did that get fixed meanwhile?

grauzone, el  4 de noviembre a las 20:23 me escribiste:
> Leandro Lucarella wrote:
> >grauzone, el  4 de noviembre a las 17:23 me escribiste:
> >>Walter Bright wrote:
> >>>Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
> >>And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows.
> >>
> >>And no, GNU ld is not too slow.
> >
> >And if you really find it slow, GNU Gold (done by Google) is *much*
> >faster.
> 
> Last I heard from it, Gold (or dmd?) had some bugs which made it unusable with dmd. Did that get fixed meanwhile?

Yes, I reported the bug[1] and it has been fixed in DMD 1.046 and 2.031.

[1] http://d.puremagic.com/issues/show_bug.cgi?id=2932

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
... los cuales son susceptibles a una creciente variedad de ataques previsibles,
tales como desbordamiento del tampón, falsificación de parámetros, ...
	-- Stealth - ISS LLC - Seguridad de IT

grauzone wrote:
> And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows.

I've spent many hours trying to find workarounds for ld problems and undocumented behaviors. The prime suspect in dmd not working on Snow Leopard is a change in the linker behavior.


> And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you).

Do you mean incremental linking or incremental compiling?


> Additionally, I prefer a slow, working linker over a fast, crashing one.

Of course. No argument there.

Walter Bright wrote:
> grauzone wrote:
>> And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows.
> 
> I've spent many hours trying to find workarounds for ld problems and undocumented behaviors. The prime suspect in dmd not working on Snow Leopard is a change in the linker behavior.

I bet OPTLINK caused more work than ld for both you and your users in summary.

Anyway, it's your software, your decisions etc...

>> And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you).
> 
> Do you mean incremental linking or incremental compiling?

Compiling. I think it had to do with emitting code for templates. DSSS (rebuild) had the same problem, and its author just gave up and called dmd once per source file, which made it awfully slow.

xfbuild (Tom S is its author, isn't he?) incremental building still doesn't work for me because of the same issue.

>> Additionally, I prefer a slow, working linker over a fast, crashing one.
> 
> Of course. No argument there.

On Nov 5, 09 02:21, Leandro Lucarella wrote:
> grauzone, el  4 de noviembre a las 17:23 me escribiste:
>> Walter Bright wrote:
>>> Anyhow, during this process I stumbled upon what the problem was.
>>> Optlink was apparently trying to account for some Borland obscure
>>> extension to the OMF. Remove this, and it works, although
>>> presumably it will no longer link Borland object files (who
>>> cares!).
>>
>> And during all that time, GNU ld worked just fine, completely
>> without bugs! I had to add hacks to my code to make it linkable on
>> Windows.
>>
>> And no, GNU ld is not too slow.
>
> And if you really find it slow, GNU Gold (done by Google) is *much*
> faster.
>
But gold is ELF only, which is irrelevant for Windows.

On 03/11/2009 23:18, Walter Bright wrote:
> Yigal Chripun wrote:
>> Once Optlink is moved to C and than D, it could grow new features like
>> link-time optimizations.
>
> It does open up a lot of possibilities.
>
> One I think would be of big benefit is for two COMDATs with different
> names, but the same contents, being merged. This would eliminate a lot
> of template bloat.

I think this could give DWT the necessary new breath...

grauzone wrote:
> Walter Bright wrote:
>> grauzone wrote:
>>> And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you).
>>
>> Do you mean incremental linking or incremental compiling?
> 
> Compiling. I think it had to do with emitting code for templates. DSSS (rebuild) had the same problem, and its author just gave up and called dmd once per source file, which made it awfully slow.
> 
> xfbuild (Tom S is its author, isn't he?) incremental building still doesn't work for me because of the same issue.

The template emission method that DMD employs is a nice optimization, however until http://d.puremagic.com/issues/show_bug.cgi?id=3327 is fixed, incremental building may still be in trouble (and thus an option to control the emission might be useful). Additionally, http://d.puremagic.com/issues/show_bug.cgi?id=3328 is hindering the potential speed of an experimental incremental build tool I've created to work with the template emission optimization. The latter issue should be quite simple to to fix, but the former looks rather tricky and might be hitting some limitations of OMF.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Am 04.11.2009, 20:08 Uhr, schrieb Bill Baxter <wbaxter@gmail.com>:

> Interesting.
>
> Detailed series of 20 blog posts by the author here:
>
> http://www.airs.com/blog/archives/38
> http://www.airs.com/blog/archives/39
> ...
> http://www.airs.com/blog/archives/57
>
> Looks like interesting reading.

Hi, wow. Great stuff. Saved and put into my knowledge-base archive. Robert

Tue, 03 Nov 2009 10:39:13 -0800, Walter Bright wrote:

> Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function.
> 
> [...]
> 
> Once it is in C and working, it will be trivial to translate it to D and start rewriting it.
> 
> Anyhow, during this process I stumbled upon what the problem was.

That's definitely good news!

Actually, I'm slowly working on a D linker myself.  Writing it in D, from scratch.  My goal is to allow linking a mix of OMF and COFF objects and libraries into the same executable, obviating the need for any conversion.  I wonder if it's feasible to continue my work.  I'm just a couple baby steps beyond the rough design stage.

Well, probably I'll continue anyway, as long as I've got the courage.  I like to re-invent wheels after all.

Sergey Gromov wrote:
> Actually, I'm slowly working on a D linker myself.  Writing it in D,
> from scratch.  My goal is to allow linking a mix of OMF and COFF objects
> and libraries into the same executable, obviating the need for any
> conversion.  I wonder if it's feasible to continue my work.  I'm just a
> couple baby steps beyond the rough design stage.
> 
> Well, probably I'll continue anyway, as long as I've got the courage.  I
> like to re-invent wheels after all.

Building a linker itself is probably not too useful, given that it'll be hard to compete with optlink. What would be cool, though, is a linker that is able to do more advanced things - like organizing the code to minimize page loading, eliminating functions that are identical except for the name, etc.