GSOC Linker project

[Alex Rønne Petersen]

On 04-05-2012 01:57, H. S. Teoh wrote:
> On Fri, May 04, 2012 at 12:53:02AM +0200, Alex Rønne Petersen wrote:
>> On 04-05-2012 00:47, Pierre LeMoine wrote:
> [...]
>>> Anyway, the project would aim to be a replacement or alternative to
>>> optlink on windows. I've personally encountered quite a few seemingly
>>> random problems with optlink, and the error messages are not exactly
>>> friendly. My vision is to create a linker in a relatively modern
>>> language (D) and to release the project as open source.
>>
>> Sounds like a good idea to me. Though in my personal opinion, you
>> should try to make the linker as platform-agnostic as possible, so
>> it's easy to adapt for new platforms / file formats.
> [...]
>
> The problem with writing linkers is that they are usually closely tied
> to implementation details on the host OS. At the very least, they must
> play nice with the OS's runtime dynamic linker (or *be* the dynamic
> linker themselves, like ld on the *nixes). They must also play nice with
> object files produced by other compilers on that platform, since
> otherwise it sorta defeats the purpose of rewriting optlink in the first
> place. This means that they must understand all the intimate details of
> every common object file and executable format on that OS.

I know, but that doesn't mean you can't write the linker so that it 
actually *is* portable at *all* (unlike a certain other linker ;).

>
> The basic concept behind a linker is very simple, really, but it's the
> implementation where details get ugly.
>
> To be frank, I question the wisdom of not just using ld on Posix
> systems... but OTOH, the world *needs* better linker technology than we
> currently have, so this projects like this one is a good thing.

Well, there's currently an LLVM linker in the works. If anything, that's 
probably the way forward. But seeing as DMD is not using LLVM...

>
> Linkers date from several decades ago, where programs can be broken up
> into separate, self-contained source files in a simple way. Things have
> changed a lot since then.  Nowadays, we have template functions, virtual
> functions, dynamic libraries, etc., which require hacks like weak
> symbols to work properly. And we're *still* missing a sound conceptual
> framework for things like cross-module dead code elimination,
> cross-module template instantiation, duplicate code merging (like
> overlapping immutable arrays), etc.. These things _sorta_ work right
> now, but they're sorta hacked on top of basic 30-year-old linker
> technology, rather than being part of a sound, conceptual linker
> paradigm.
>
>
> T
>

-- 
- Alex