Walter:

> While it's nice to demangle the names, and optlink does so for C++ names, it doesn't reduce the confusion about what the linker is doing. Surprisingly, I see these questions not just from newbies, but regularly from people with 10+ years of experience.

What the linker is doing is something that conceptually is not complex, so an average programmer is supposed to understand what are the problems a linker may encounter in its work.

Yet clearly some newbie programmers don't understand those linker errors, this is one recent example (and I have seen two or three other similar questions):
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22731

Quotation from that post:

> test.d:(.text._Dmain+0x9): undefined reference to `_D7libtest3funFiZi' collect2: ld returned 1 exit status
> --- errorlevel 1
> 
> I have no troubles with standard libraries, just mine's. I have the dmd 2.0.50 compiler on a GNU/Linux 64bit system. Any idea?

A better error message is probably able to avoid similar requests for help. A better error message spares the need for the newbie D programmer to know what the linker is doing (eventually to program in D seriously you need to know why the linker is working, but asking such knowledge from day zero is not wise, especially because some future D programmer may come from JavaScript, Python, Ruby, Java, etc where there is no experience about linkers).

Recently you have modified the error messages, so this D2 program:

void main() {
    writeln("Hello world!");
}

Now gives an error message useful for the D newbie:

test.d(2): Error: 'writeln' is not defined, perhaps you need to import std.stdio; ?

Helping the newbie with the linker errors will be similarly useful (even better is to DMD to find its needed modules by itself on default, unless a compiler switch is used to disable this feature. I think this solves the problem. It's good for newbies, it's good for small or script-like D programs, and for more serious usages of D you just need to add the disabling switch in the command line).

Bye,
bearophile

bearophile wrote:
> What the linker is doing is something that conceptually is not complex, so an
> average programmer is supposed to understand what are the problems a linker
> may encounter in its work.

The linker is a conceptually *trivial* program. It baffles me why programmers with 10+ years of experience in C and C++ are stumped by "undefined symbol" messages, cannot look at a linker map file, etc.

It's like being a C programmer and not knowing what a pointer is.

On Thu, 11 Nov 2010 18:28:08 -0500
bearophile <bearophileHUGS@lycos.com> wrote:

> Walter:
> 
> > While it's nice to demangle the names, and optlink does so for C++ names, it doesn't reduce the confusion about what the linker is doing. Surprisingly, I see these questions not just from newbies, but regularly from people with 10+ years of experience.
> 
> What the linker is doing is something that conceptually is not complex, so an average programmer is supposed to understand what are the problems a linker may encounter in its work.
> 
> Yet clearly some newbie programmers don't understand those linker errors, this is one recent example (and I have seen two or three other similar questions):
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22731
> 
> Quotation from that post:
> 
> > test.d:(.text._Dmain+0x9): undefined reference to `_D7libtest3funFiZi' collect2: ld returned 1 exit status
> > --- errorlevel 1
> > 
> > I have no troubles with standard libraries, just mine's. I have the dmd 2.0.50 compiler on a GNU/Linux 64bit system. Any idea?
> 
> A better error message is probably able to avoid similar requests for help. A better error message spares the need for the newbie D programmer to know what the linker is doing (eventually to program in D seriously you need to know why the linker is working, but asking such knowledge from day zero is not wise, especially because some future D programmer may come from JavaScript, Python, Ruby, Java, etc where there is no experience about linkers).
> 
> Recently you have modified the error messages, so this D2 program:
> 
> void main() {
>     writeln("Hello world!");
> }
> 
> Now gives an error message useful for the D newbie:
> 
> test.d(2): Error: 'writeln' is not defined, perhaps you need to import std.stdio; ?

This is really great! Thinking that way at newcomers, at their points of view, is not only nice, but probably one of the best srategies to enlarge D's adoption in the long term. People should feel welcome.

> Helping the newbie with the linker errors will be similarly useful (even better is to DMD to find its needed modules by itself on default, unless a compiler switch is used to disable this feature. I think this solves the problem. It's good for newbies, it's good for small or script-like D programs, and for more serious usages of D you just need to add the disabling switch in the command line).

But this may not be done in the general case. What if the name of the undefined symbol the programmer intends to use only happens to match one of the std lib's? (and maybe various modules of the std lib define symbols with the same names?)


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

On Thu, 11 Nov 2010 20:03:21 -0500, Walter Bright <newshound2@digitalmars.com> wrote:

> bearophile wrote:
>> What the linker is doing is something that conceptually is not complex, so an
>> average programmer is supposed to understand what are the problems a linker
>> may encounter in its work.
>
> The linker is a conceptually *trivial* program. It baffles me why programmers with 10+ years of experience in C and C++ are stumped by "undefined symbol" messages, cannot look at a linker map file, etc.
>
> It's like being a C programmer and not knowing what a pointer is.

Where is the linker in this line?

dmd a.d b.d

The problem I see is that the compilers of today hide the fact that a linker is being used.  A lot of coders now use IDEs and don't even know how to use the compiler directly, let alone the linker.

Just the other day, I was "baffled" by a link error, where a symbol was multiply defined (C project).  The answer was this problem:

#include "module1.h"
#include "module2.c"

Took me a while to see it :) (note I didn't write this, a co-worker who has very little experience with C did :)

I guess it's not so much we don't understand that the linker can't find the object, or that it's multiply defined, it's just hard to connect that with the root cause.  More information never hurts, and let's face it, we have a computer at our disposal!  One that has suddenly been given a lot of free time because it's no longer compiling.  Having it figure out as much as it can is beneficial to all.

Back to the problem at hand though, if the linker could demangle the symbol, or some wrapper could, people would have a much better idea of where the problem is.  I don't care how many years experience you have, if you can demangle symbols in your head, you are one of a gifted few.  I shouldn't have to get out my decoder ring to understand linker errors.

-Steve