On 11/02/2022 11:52 AM, Walter Bright wrote:
> I have never been able to explain these to people. I wonder if it is because it is so simple, people think "that can't be right". With the hook thing, they'll ask me to re-explain it several times, then they'll say "are you sure?" and they still don't believe it.

It does depend on a few factors.

Compiler, linker, build/package manager all playing along.

Not to mention shared library support actually good enough with clear common use cases all described.

For me personally there are a few unknowns for the general case that I would avoid using it in production.

On 2/10/2022 4:03 PM, rikki cattermole wrote:
> On 11/02/2022 11:52 AM, Walter Bright wrote:
>> I have never been able to explain these to people. I wonder if it is because it is so simple, people think "that can't be right". With the hook thing, they'll ask me to re-explain it several times, then they'll say "are you sure?" and they still don't believe it.
> 
> It does depend on a few factors.
> 
> Compiler, linker, build/package manager all playing along.
> 
> Not to mention shared library support actually good enough with clear common use cases all described.
> 
> For me personally there are a few unknowns for the general case that I would avoid using it in production.

All linkers work this way.

On Thursday, 10 February 2022 at 22:52:45 UTC, Walter Bright wrote:
> On 2/10/2022 2:06 PM, Dave P. wrote:
>> Undefined symbols for architecture arm64:
>>    "__D7example9some_funcFiZi", referenced from:
>>        __D7example3fooFiZi in example.o
>>        __D7example3barFiZi in example.o
>>        __D7example3bazFiZi in example.o
>>        __D7example3quxFiZi in example.o
>>        __Dmain in example.o
>> ld: symbol(s) not found for architecture arm64
>
> Things I have never been able to explain, even to long time professional programmers:
>
> 1. what "undefined symbol" means
>
> 2. what "multiply defined symbol" means
>
> 3. how linkers resolve symbols
>
> Our own runtime library illustrates this bafflement. In druntime, there are these "hooks" where one can replace the default function that deals with assertion errors.
>
> Such hooks are entirely unnecessary.
>
> To override a symbol in a library, just write your own function with the same name and link it in before the library.
>
> I have never been able to explain these to people. I wonder if it is because it is so simple, people think "that can't be right". With the hook thing, they'll ask me to re-explain it several times, then they'll say "are you sure?" and they still don't believe it.

If by hook you mean a callback of sorts that can be overrided, then the problem solved is not strictly the same as a weakly defined function. If you have multiple library's in the same playpen then it simply doesn't work to have them all trying to override the same symbols. If they can neatly hook and unhook things that goes away.

On 2/10/2022 7:45 PM, max haughton wrote:
> If by hook you mean a callback of sorts that can be overrided, then the problem solved is not strictly the same as a weakly defined function. If you have multiple library's in the same playpen then it simply doesn't work to have them all trying to override the same symbols. If they can neatly hook and unhook things that goes away.

That's not how multiple libraries work.

Suppose you have 3 libraries, A, B, and C. You have an object file X. The linker command is:

    link X.obj A.lib B.lib C.lib

X refers to "foo". All 4 define "foo". Which one gets picked?

   X.foo

That's it. There are no unresolved symbols to look for.

Now, suppose only B and C define "foo". Which one gets picked?

   B.foo

because it is not in X. Then, A is looked at, and it is not in A. Then, B is looked at, and it is in B. C is not looked at because it is now resolved.

It has nothing to do with weak definitions. It's a simple "foo" is referenced. Got to find a definition. Look in the libraries in the order they are supplied to the linker.

That's it.

Want to not use the library definition? Define it yourself in X. No need for hooking. No need for anything clever at all. Just define it in your .obj file.

----

Now suppose X.obj and Y.obj both define foo. Link with:

    link X.obj Y.obj A.lib B.lib C.lib

You get a message:

    Multiple definition of "foo", found in X.obj and Y.obj

because order does not matter for .obj files as far as symbols go. All the symbols in .obj files get added.

On 2/10/2022 8:18 PM, Era Scarecrow wrote:
>   To note, back in 1996 or about there i wrote an assembler that took x86 and could compiler itself. But wasn't compatible with any other code and couldn't use object files or anything (*as it was all made from scratch when i was 12-14*). However it did compiler directly to a COM file. I'll just say from experience, there are advantages but they don't outweigh the disadvantages. That's my flat opinion going from here.

Back in the olden days, creating a DOS executable was trivial. Things have gotten much more complicated.