www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - linker wrapper

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
Just saw another linker error in d.learn, and it got me thinking

dmd just calls the linker, and the linker spits out link errors.  But what  
if we had a 'linker wrapper' program which translated mangled names into  
demangled names?  It would at least help people understand the problem  
better.  How many times does a newbie come back and say "I have this  
problem, and dmd spits out some weird message I don't understand" and it  
takes a person who half-speaks mangled d names to understand what the name  
is.

Given that D already includes a demangler, wouldn't it be rather trivial  
to write this program in D?

I know it would make my life a bit better.

Thoughts?  Takers?

-Steve
Nov 11 2010
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 11 Nov 2010 15:54:50 +0300, Steven Schveighoffer  =

<schveiguy yahoo.com> wrote:


 Just saw another linker error in d.learn, and it got me thinking

 dmd just calls the linker, and the linker spits out link errors.  But =


 =


 what if we had a 'linker wrapper' program which translated mangled nam=


es  =


 into demangled names?  It would at least help people understand the  =



 problem better.  How many times does a newbie come back and say "I hav=


e  =


 this problem, and dmd spits out some weird message I don't understand"=


  =


 and it takes a person who half-speaks mangled d names to understand wh=


at  =


 the name is.

 Given that D already includes a demangler, wouldn't it be rather trivi=


al  =


 to write this program in D?

 I know it would make my life a bit better.

 Thoughts?  Takers?

 -Steve


I suggested that previously [1], and I think that need to be a part of D=
MD  =

for a simple reason: some of the names can't be demangled because their =
 =

are somewhat "hashed" to avoid limitations such as long literal name. E.=
g.  =

"_D4math6M=D0=B1rix9=D1=8544F32__T3addTC=D0=82=E2=80=93=D0=8EZ=D0=82=E2=80=
=9E=D1=9CF=D0=82=E2=80=94=D1=9C=D0=82=C2=98=D2=91=D0=82=E2=80=94=C2=98".=


Given that dmd calls a linker internally, it could also retrieve linker =
 =

errors (if any present), translate and then show them, with a list of  =

suggestions to fix the problem if possible. Here are an example:

module test1;
void foo() {}

module test2;
import test1;
void main() { foo(); }

#dmd test2.d

Desired output: Error: No implementation found for method void foo()  =

defined in module test1. Try linking with test1.d
Actual output: Error 42: Symbol Undefined _D5test13fooFZv

[1] http://d.puremagic.com/issues/show_bug.cgi?id=3D2238
Nov 11 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:


 Given that dmd calls a linker internally, it could also retrieve linker  
 errors (if any present), translate and then show them, with a list of  
 suggestions to fix the problem if possible. Here are an example:
 
 module test1;
 void foo() {}
 
 module test2;
 import test1;
 void main() { foo(); }
 
 #dmd test2.d
 
 Desired output: Error: No implementation found for method void foo()  
 defined in module test1. Try linking with test1.d
 Actual output: Error 42: Symbol Undefined _D5test13fooFZv
 
 [1] http://d.puremagic.com/issues/show_bug.cgi?id=2238


I have just suggested a similar error message in D.learn newsgroup. Of course
the compiler can also do the damm thing by itself and find the module it needs
(this feature may be disable with a compiler switch, for larger compilations,
do-it-yourself-people, etc).

Bye,
bearophile
Nov 11 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 11 Nov 2010 08:20:46 -0500, Denis Koroskin <2korden gmail.com>  
wrote:


 On Thu, 11 Nov 2010 15:54:50 +0300, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:


 Just saw another linker error in d.learn, and it got me thinking

 dmd just calls the linker, and the linker spits out link errors.  But  
 what if we had a 'linker wrapper' program which translated mangled  
 names into demangled names?  It would at least help people understand  
 the problem better.  How many times does a newbie come back and say "I  
 have this problem, and dmd spits out some weird message I don't  
 understand" and it takes a person who half-speaks mangled d names to  
 understand what the name is.

 Given that D already includes a demangler, wouldn't it be rather  
 trivial to write this program in D?

 I know it would make my life a bit better.

 Thoughts?  Takers?

 -Steve


 I suggested that previously [1], and I think that need to be a part of  
 DMD for a simple reason: some of the names can't be demangled because  
 their are somewhat "hashed" to avoid limitations such as long literal  
 name. E.g. "_D4math6Mбrix9х44F32__T3addTCЂ–ЎZЂ„ќFЂ—ќЂ˜ґЂ—˜".


Not sure we can do anything about that, if we're only giving dmd object  
files to work with.

I think we need to implement something different in terms of 'hashing'.   
It's another idea I've had, but not sure if I've expressed it.  Typically,  
you have things like this in a module:

struct Y(T) {}

struct X(T)
{
    void foo(Y!T y) {...}
}

where this is in std.amodule.  The seemingly small foo symbol gets  
exploded to the equivalent of:

std.amodule.X!int.foo(std.amodule.Y!int)

I see a lot of repetition in there.  I think we can do some kind of  
lossless compression with name mangling so you represent repetetive  
symbols such as module names and type parameters as back references.

These would also be demangleable.


 Given that dmd calls a linker internally, it could also retrieve linker  
 errors (if any present), translate and then show them, with a list of  
 suggestions to fix the problem if possible. Here are an example:

 module test1;
 void foo() {}

 module test2;
 import test1;
 void main() { foo(); }

 #dmd test2.d

 Desired output: Error: No implementation found for method void foo()  
 defined in module test1. Try linking with test1.d
 Actual output: Error 42: Symbol Undefined _D5test13fooFZv


This would be cool too.  BTW, does anyone know if the linkers used by DMD  
allow options to output easily-parsable errors?

-Steve
Nov 11 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/10 5:32 AM, Steven Schveighoffer wrote:

 On Thu, 11 Nov 2010 08:20:46 -0500, Denis Koroskin <2korden gmail.com>
 wrote:


 On Thu, 11 Nov 2010 15:54:50 +0300, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:


 Just saw another linker error in d.learn, and it got me thinking

 dmd just calls the linker, and the linker spits out link errors. But
 what if we had a 'linker wrapper' program which translated mangled
 names into demangled names? It would at least help people understand
 the problem better. How many times does a newbie come back and say "I
 have this problem, and dmd spits out some weird message I don't
 understand" and it takes a person who half-speaks mangled d names to
 understand what the name is.

 Given that D already includes a demangler, wouldn't it be rather
 trivial to write this program in D?

 I know it would make my life a bit better.

 Thoughts? Takers?

 -Steve


 I suggested that previously [1], and I think that need to be a part of
 DMD for a simple reason: some of the names can't be demangled because
 their are somewhat "hashed" to avoid limitations such as long literal
 name. E.g. "_D4math6Mбrix9х44F32__T3addTCЂ–ЎZЂ„ќFЂ—ќЂ˜ґЂ—˜".


 Not sure we can do anything about that, if we're only giving dmd object
 files to work with.

 I think we need to implement something different in terms of 'hashing'.
 It's another idea I've had, but not sure if I've expressed it.
 Typically, you have things like this in a module:

 struct Y(T) {}

 struct X(T)
 {
 void foo(Y!T y) {...}
 }

 where this is in std.amodule. The seemingly small foo symbol gets
 exploded to the equivalent of:

 std.amodule.X!int.foo(std.amodule.Y!int)

 I see a lot of repetition in there. I think we can do some kind of
 lossless compression with name mangling so you represent repetetive
 symbols such as module names and type parameters as back references.

 These would also be demangleable.


 Given that dmd calls a linker internally, it could also retrieve
 linker errors (if any present), translate and then show them, with a
 list of suggestions to fix the problem if possible. Here are an example:

 module test1;
 void foo() {}

 module test2;
 import test1;
 void main() { foo(); }

 #dmd test2.d

 Desired output: Error: No implementation found for method void foo()
 defined in module test1. Try linking with test1.d
 Actual output: Error 42: Symbol Undefined _D5test13fooFZv


 This would be cool too. BTW, does anyone know if the linkers used by DMD
 allow options to output easily-parsable errors?

 -Steve


Apparently gnu's ld demangles by default:

http://linux.die.net/man/1/ld

(Search for "demangle".) But it recognizes C++ mangling, not D mangling.


Andrei
Nov 11 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Apparently gnu's ld demangles by default:
 
 http://linux.die.net/man/1/ld
 
 (Search for "demangle".) But it recognizes C++ mangling, not D mangling.


The same for optlink.
Nov 11 2010
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
Denis Koroskin wrote:

 I suggested that previously [1], and I think that need to be a part of 
 DMD for a simple reason: some of the names can't be demangled because 
 their are somewhat "hashed" to avoid limitations such as long literal 
 name. E.g. "_D4math6Mбrix9х44F32__T3addTCЂ–ЎZЂ„ќFЂ—ќЂ˜ґЂ—˜".


This is not a "hashed" symbol, it is compressed and can be converted 
back to the mangled string. The latest svn version of core.demangle has 
a function to decompress it.

An example of a "hashed" symbol is

_D3dmd19TemplateDeclaration19TemplateDeclaration27deduceFunctionTemplateMatchMFS3dmd3Loc3LocC3dmECA03C220132A92B4B4768C252AA61AC

It cannot be fully demangled (though just demangling the symbol name 
without type information should work most of the time and could already 
be helpful).

I've seen dmd using a third way dealing with strings longer than 255 
characters: instead of a single byte the length is encoded as 0xff 0x00, 
LSB, MSB before the symbol characters.

Walter, is optlink able to deal with this 3rd representation in all 
places, so we can get rid of those other two encodings?

I was also considering adding the demangling to the build output parsing 
of Visual D, but somehow didn't yet get to it. Please note that 
sometimes mangled names are also used in error messages produced by dmd.

Rainer
Nov 11 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Rainer Schuetze wrote:

 
 Denis Koroskin wrote:

 I suggested that previously [1], and I think that need to be a part of 
 DMD for a simple reason: some of the names can't be demangled because 
 their are somewhat "hashed" to avoid limitations such as long literal 
 name. E.g. "_D4math6Mбrix9х44F32__T3addTCЂ–ЎZЂ„ќFЂ—ќЂ˜ґЂ—˜".


 
 This is not a "hashed" symbol, it is compressed and can be converted 
 back to the mangled string. The latest svn version of core.demangle has 
 a function to decompress it.
 
 An example of a "hashed" symbol is
 
 _D3dmd19TemplateDeclaration19TemplateDeclaration27deduceFunctionTemplateMatchMFS3dmd3Loc3LocC3dmECA03C220132
92B4B4768C252AA61AC 
 
 
 It cannot be fully demangled (though just demangling the symbol name 
 without type information should work most of the time and could already 
 be helpful).
 
 I've seen dmd using a third way dealing with strings longer than 255 
 characters: instead of a single byte the length is encoded as 0xff 0x00, 
 LSB, MSB before the symbol characters.
 
 Walter, is optlink able to deal with this 3rd representation in all 
 places, so we can get rid of those other two encodings?


The way long symbols on Windows are dealt with:

1. if they fit, they fit
2. try using the extended length method
3. try compressing the string
4. use a hash for the string

1..3 are reversible, 4 is not.


 
 I was also considering adding the demangling to the build output parsing 
 of Visual D, but somehow didn't yet get to it. Please note that 
 sometimes mangled names are also used in error messages produced by dmd.
 
 Rainer
Nov 11 2010
parent Rainer Schuetze <r.sagitario gmx.de> writes:
Walter Bright wrote:

 Rainer Schuetze wrote:

 Walter, is optlink able to deal with this 3rd representation in all 
 places, so we can get rid of those other two encodings?


 
 The way long symbols on Windows are dealt with:
 
 1. if they fit, they fit
 2. try using the extended length method
 3. try compressing the string
 4. use a hash for the string
 
 1..3 are reversible, 4 is not.
 


Doing it always in this order would be fine, because 2. is bound to 
never fail.

Checking the source (but probably missing some places), I see that

- obj_namestring uses 1,2
- obj_mangle uses 1,3,4,2 with a length limit of 128
- Library::FillDict uses 1,2, but might crash due to limited buffer size 
(for symbols longer than 468 characters - is this a limitation of the 
library format?)
- cv_namestring uses 1,2

So I tried compiling ddmd skipping 3 and 4 in obj_mangle, but that 
caused crashes for symbols longer than IDMAX (=900). Increasing that 
limit (max length was >5600) caused a crash in optlink. But as far as I 
can see, limiting the usage of 3 and 4 to symbols longer than IDMAX 
seems to work (though I have not done any more testing). Actually, this 
version is already in the code, but deliberately replaced by the limit 
of 128 characters, so there might be a reason...

Rainer
Nov 12 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/10 4:54 AM, Steven Schveighoffer wrote:

 Just saw another linker error in d.learn, and it got me thinking

 dmd just calls the linker, and the linker spits out link errors. But
 what if we had a 'linker wrapper' program which translated mangled names
 into demangled names? It would at least help people understand the
 problem better. How many times does a newbie come back and say "I have
 this problem, and dmd spits out some weird message I don't understand"
 and it takes a person who half-speaks mangled d names to understand what
 the name is.

 Given that D already includes a demangler, wouldn't it be rather trivial
 to write this program in D?

 I know it would make my life a bit better.

 Thoughts? Takers?

 -Steve


Would love to see this implemented. Mangled symbols are the main reason 
for which linker messages are considered incomprehensible.

Andrei
Nov 11 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Mangled symbols are the main reason 
 for which linker messages are considered incomprehensible.


I beg to differ. The same confusion appears when linking C programs, where the 
names are not mangled.

Top 3 linker questions:

1. What does it mean when it says "foo is referenced but not defined" ?

2. What does it mean when it says that "foo is defined in more than one module"
?

3. Why is my executable file so large?


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.
Nov 11 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Nov 11 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 11 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Nov 12 2010
prev sibling parent spir <denis.spir gmail.com> writes:
On Thu, 11 Nov 2010 18:28:08 -0500
bearophile <bearophileHUGS lycos.com> wrote:


 Walter:
=20

 While it's nice to demangle the names, and optlink does so for C++ name=




s, it=20

 doesn't reduce the confusion about what the linker is doing. Surprising=




ly, I see=20

 these questions not just from newbies, but regularly from people with 1=




0+ years=20

 of experience.


=20
 What the linker is doing is something that conceptually is not complex, s=


o an average programmer is supposed to understand what are the problems a l=
inker may encounter in its work.

=20
 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 que=
stions):

 http://www.digitalmars.com/webnews/newsgroups.php?art_group=3Ddigitalmars=


.D.learn&article_id=3D22731

=20
 Quotation from that post:
=20

 test.d:(.text._Dmain+0x9): undefined reference to `_D7libtest3funFiZi'
 collect2: ld returned 1 exit status
 --- errorlevel 1
=20
 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?


=20
 A better error message is probably able to avoid similar requests for hel=


p. A better error message spares the need for the newbie D programmer to kn=
ow 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 Java=
Script, Python, Ruby, Java, etc where there is no experience about linkers).

=20
 Recently you have modified the error messages, so this D2 program:
=20
 void main() {
     writeln("Hello world!");
 }
=20
 Now gives an error message useful for the D newbie:
=20
 test.d(2): Error: 'writeln' is not defined, perhaps you need to import st=


d.stdio; ?

This is really great! Thinking that way at newcomers, at their points of vi=
ew, 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 pr=
oblem. 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 switc=
h in the command line).

But this may not be done in the general case. What if the name of the undef=
ined 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 th=
e same names?)


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 12 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 Top 3 linker questions:
 
 1. What does it mean when it says "foo is referenced but not defined" ?
 
 2. What does it mean when it says that "foo is defined in more than one
module" ?
 
 3. Why is my executable file so large?
 
 
 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.


A new fresh trouble, I think I have already seen about 10-15 persons ask this
question in D.learn:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22772

Bye,
bearophile
Nov 13 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 A new fresh trouble, I think I have already seen about 10-15 persons ask this
question in D.learn:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22772


http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined
Nov 13 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 bearophile wrote:

 A new fresh trouble, I think I have already seen about 10-15 persons ask this
question in D.learn:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22772


 
 http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined


Probably we'll see more people asking for that kind of help. Not all D newbies
come from languages that use a linker. Today a significant and growing

The linker is currently present in the D world, and you can't hide this fact
(but simpler to understand error messages will probably help a lot).

My preferred (partial) solution to that problem is to let DMD look by itself
for the modules it needs to compile a program, unless a compiler switch asks
otherwise and restores the simpler basic behaviour. This helps D newbies,
people that write small programs, and causes exactly zero troubles to people
that compile large D programs or people that want partial compilation anyway.
This doesn't solve all linker troubles, because linker errors may have other
causes, but removes the most common one for D newbies and is useful for other
purposes too.

Bye,
bearophile
Nov 13 2010
parent reply Andrew Wiley <debio264 gmail.com> writes:
On Sat, Nov 13, 2010 at 5:02 PM, bearophile <bearophileHUGS lycos.com>wrote:


 Walter Bright:


 bearophile wrote:

 A new fresh trouble, I think I have already seen about 10-15 persons




 ask this question in D.learn:




 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22772


 http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined

 Probably we'll see more people asking for that kind of help. Not all D
 newbies come from languages that use a linker. Today a significant and

 Python, etc. The linker is currently present in the D world, and you can't
 hide this fact (but simpler to understand error messages will probably help
 a lot).

 My preferred (partial) solution to that problem is to let DMD look by
 itself for the modules it needs to compile a program, unless a compiler
 switch asks otherwise and restores the simpler basic behaviour. This helps D
 newbies, people that write small programs, and causes exactly zero troubles
 to people that compile large D programs or people that want partial
 compilation anyway. This doesn't solve all linker troubles, because linker
 errors may have other causes, but removes the most common one for D newbies
 and is useful for other purposes too.


I would argue that while helpful error messages are... helpful, but having
the compiler or linker change what you said to what it thinks you meant
seems likely to cause unintended behavior and become a crutch. Learning to
operate a compiler and linker is a fundamental part of programming pretty
much any compiled language, and taking it away encourages the user to not
care how their code becomes an executable. To me, this seems like a large
disservice.



 Nov 13 2010



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Andrew Wiley:


 Learning to
 operate a compiler and linker is a fundamental part of programming pretty
 much any compiled language, and taking it away encourages the user to not
 care how their code becomes an executable. To me, this seems like a large
 disservice.


Many new programmers don't want to know how to read linker mangled error
messages, how to use a linker, or sometimes even what a linker is. Less and
less people will want to use languages that force people to know those things.
I have used Delphi for medium sized programs not caring much about its linker.

If you don't even see the usefulness of more readable linker errors then... why
are where here? Aren't we trying to improve older languages? :-)

Bye,
bearophile



 Nov 13 2010



  parent reply Andrew Wiley <debio264 gmail.com>  writes:


On Sat, Nov 13, 2010 at 9:14 PM, bearophile <bearophileHUGS lycos.com>wrote:

 If you don't even see the usefulness of more readable linker errors then...
 why are where here? Aren't we trying to improve older languages?



I said that improved error messages would be helpful.
I may have misinterpreted you when you said:


My preferred (partial) solution to that problem is to let DMD look by


itself for the modules it needs to >compile a program, unless a compiler
switch asks otherwise and restores the simpler basic behaviour.

I interpreted this as the compiler adding modules that were unspecified on
the command line when calling the linker. If you meant that the compiler
should search for additional required modules for more useful error
messages, I agree with that sentiment.
As written, it seems like you want the compiler to try to autodetect which
object files need to be linked together and add those objects to the
arguments to the linker, which I believe is a disservice because it takes a
simple "pure" input/output model of compilation and makes it perform actions
the programmer didn't necessarily intend or comprehend.



 Nov 13 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Andrew Wiley wrote:

 I interpreted this as the compiler adding modules that were unspecified 
 on the command line when calling the linker. If you meant that the 
 compiler should search for additional required modules for more useful 
 error messages, I agree with that sentiment.
 As written, it seems like you want the compiler to try to autodetect 
 which object files need to be linked together and add those objects to 
 the arguments to the linker, which I believe is a disservice because it 
 takes a simple "pure" input/output model of compilation and makes it 
 perform actions the programmer didn't necessarily intend or comprehend.


I suspect that trying to guess what modules should be added to the linker list 
may cause far more confusion than enlightenment when it goes awry. Currently, a 
lot of people seem to regard what a linker does as magic. Making it more
magical 
won't help.



 Nov 13 2010



  parent reply Rainer Deyke <rainerd eldwood.com>  writes:


On 11/14/2010 00:09, Walter Bright wrote:

 I suspect that trying to guess what modules should be added to the
 linker list may cause far more confusion than enlightenment when it goes
 awry. Currently, a lot of people seem to regard what a linker does as
 magic. Making it more magical won't help.


It seems completely straightforward to me.  If module A imports module
B, then module A depends on module B, therefore compiling and linking
module A should also cause module B to be compiled and linked.  Apply
recursively.  The only part of this that is remotely difficult - mapping
module names to files on the disk - is already done by the compiler.

This would only happen when compiling and linking as a single step,
which would be the preferred way to invoke DMD.  When linking as a
separate step, all object files would still need to be individually
passed to the linker.


-- 
Rainer Deyke - rainerd eldwood.com



 Nov 14 2010



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Rainer Deyke wrote:

 On 11/14/2010 00:09, Walter Bright wrote:

 I suspect that trying to guess what modules should be added to the
 linker list may cause far more confusion than enlightenment when it goes
 awry. Currently, a lot of people seem to regard what a linker does as
 magic. Making it more magical won't help.


 
 It seems completely straightforward to me.  If module A imports module
 B, then module A depends on module B, therefore compiling and linking
 module A should also cause module B to be compiled and linked.  Apply
 recursively.  The only part of this that is remotely difficult - mapping
 module names to files on the disk - is already done by the compiler.
 
 This would only happen when compiling and linking as a single step,
 which would be the preferred way to invoke DMD.  When linking as a
 separate step, all object files would still need to be individually
 passed to the linker.


The compiler can't tell:

1. if the implementation of a particular import is in a library or an object
file.

2. if the object file is not in the same place as the import file

So you might say "let's use some reasonable defaults for these."

Ok, but when that goes awry (and it absolutely will), there will be left behind 
some very confused people. Consider that I regularly get requests for help from 
people who are linking with the wrong version of phobos.lib which they insist 
does not exist on their computer. Eventually, it turns out that it did exist
and 
was on the library search path. This problem would get much, much worse.

Object file names do not always match the import names, and there are various 
other scenarios that are not so straightforward. If the compiler goes down the 
road of defaults, and the user thinks that a.obj is being linked in while 
actually some random b.obj is, and mysterious failures happen, he's going to be 
very unhappy. I'd certainly rather have an undefined symbol message when I make 
a mistake putting together the makefile than something wrong and hidden from me 
happening.

Is this real? Yes. I also regularly get requests for help from people who do
not 
understand how objects are pulled from a library by the linker, and not just 
from vm people. They are not going to be helped by the compiler mysteriously 
linking in whatever it finds first. If they are baffled by an "undefined
symbol" 
message, they are really going to get gobsmacked by this.

To really manage this sort of thing in a way that works, you need to use an IDE 
that has a notion of a "project" and what files are in that project and where 
all the object files and libraries are.



 Nov 14 2010



prev sibling  parent reply Kagamin <spam here.lot>  writes:


bearophile Wrote:


 Probably we'll see more people asking for that kind of help. Not all D newbies
come from languages that use a linker. Today a significant and growing




but still suffers from the same problems as traditional linkers.



 Nov 15 2010



  parent  bearophile <bearophileHUGS lycos.com>  writes:


Kagamin:



builtin, but still suffers from the same problems as traditional linkers.


I generally try to talk only about the things I know something about, but I
don't know enough about linkers yet, I am sorry.

Bye,
bearophile



 Nov 15 2010