Potential of a compiler that creates the executable at once

Walter Bright newshound2 at digitalmars.com
Sat Feb 12 00:51:46 UTC 2022


On 2/11/2022 9:20 AM, max haughton wrote:
> If all the libraries rely on hooking something you will silently break all but 
> one, whereas the process of overriding a runtime hook can be made into an atomic 
> operation that can fail in a reasonable manner if wielded incorrectly.

Sorry, I don't follow that. I don't know what atomic ops have to do with it.


> Doing things based on the order at link-time is simply not good practice in the 
> general case. It's OK if you control all the things in the stack and want to 
> (say) override malloc, but controlling what happens on an assertion is exactly 
> the kind of thing that resolution at link-time can make into a real nightmare to 
> do cleanly (and mutably, you might want to catch assertions differently when 
> acting as a web server than when loading data).

All link operations conform to the ordering I described. I can't think of a way 
that is simpler, cleaner, or easier to understand. Hooking certainly ain't.


> Also linking (especially around shared libraries) doesn't work in exactly the 
> same way on all platforms, so basically maximizing the entropy of a given link 
> (minimize possible outcomes, so minimal magic) can be a real win when it comes 
> to making a program that builds and runs reliably on different platforms. At 
> Symmetry we have had real issues with shared libraries, for reasons more 
> complicated than mentioned here granted, so we actually cannot ship anything 
> with dmd even if we wanted to.

DLLs (shared libraries) are a different story because they are all-or-nothing. 
In fact, they aren't actually libraries at all in the programming sense. They 
aren't linked in, either, there's no linking involved when accessing a DLL.


More information about the Digitalmars-d mailing list