www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - To avoid some linking errors

reply "bearophile" <bearophileHUGS lycos.com> writes:
This code compiles with no errors, and then later the linker 
gives a "Symbol Undefined":


abstract class A {
     public void foo();
}
class B : A {}
void main() {}


In this bug report I have asked for the compiler to give an error:
http://d.puremagic.com/issues/show_bug.cgi?id=5129


But Walter has answered it's not a bug:


 This is not a bug, as in another module there could be a class 
 C that derives
 from B and implements foo().
 
 As documented, D accepts non-abstract functions with no body 
 declared as:
 
    void foo();
 
 with the idea that the user will be supplying a body somewhere 
 else - perhaps
 even a C function or an assembler one. It's another way of 
 doing encapsulation
 by having an opaque implementation. In fact, it's used by the 
 TypeInfo's.



Stewart Gordon suggests:


 I think the underlying problem is that there's no mandatory 
 explicit notation
 for externally defined functions.



So isn't it better to require (similarly to annotations like 
"override") the programmer to write in B an "extern" or 
"abstract" or something similar to state that the implementation 
is elsewhere (and give a nice compilation error if it's missing)?


abstract class A {
     public void foo();
}
class B : A {
	extern foo;
}
void main() {}


Or:

abstract class A {
     public void foo();
}
class B : A {
	abstract foo;
}
void main() {}


Bye,
bearophile
Oct 28 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2012 6:39 AM, bearophile wrote:

 This code compiles with no errors, and then later the linker gives a "Symbol
 Undefined":
 [...]
 (and give a nice compilation error if it's missing)?


It already gives a nice error "Symbol Undefined". I don't understand why this
is 
a problem.

   void foo() { } // defined here
   void foo();    // defined elsewhere

No need for anything more.
Oct 28 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 28/10/2012 18:17, Walter Bright a écrit :

 On 10/28/2012 6:39 AM, bearophile wrote:

 This code compiles with no errors, and then later the linker gives a
 "Symbol
 Undefined":
 [...]


  > (and give a nice compilation error if it's missing)?

 It already gives a nice error "Symbol Undefined". I don't understand why
 this is a problem.

 void foo() { } // defined here
 void foo(); // defined elsewhere

 No need for anything more.


As Andrei stated, the linker's native language is encrypted klingon.
Oct 28 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2012 1:34 PM, deadalnix wrote:

 As Andrei stated, the linker's native language is encrypted klingon.


It baffles me that programmers would find "undefined symbol" hard to make sense
of.
Oct 28 2012
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:

 It baffles me that programmers would find "undefined symbol" 
 hard to make sense of.


Do really think that your typical Java programmer is familiar 
with the term »symbol« in the compiler/linker sense? Also, 
don't underestimate the perceived scariness/ugliness of mangled 
names in linker error messages. I'm pretty much fluent in reading 
D mangled names by now, but most newcomers definitely aren't.

That, coupled with the absence of the typical source location 
information (IDE integration!), is probably enough to make 
encountering such errors a significantly more unpleasant 
experience for most people than compiler errors.

Again, maybe not for you, maybe not for me, but I think it is 
clear that this is a problem to some, so the discussion should 
not be about talking the problem away, but rather about 
evaluating possible solutions/mitigation strategies in terms of 
feasibility (e.g. name demangling in linker output?).

David
Oct 28 2012
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 28.10.2012 22:38, schrieb David Nadlinger:

 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:

 It baffles me that programmers would find "undefined symbol" hard to
 make sense of.


 Do really think that your typical Java programmer is familiar with the
 term »symbol« in the compiler/linker sense? Also, don't underestimate
 the perceived scariness/ugliness of mangled names in linker error
 messages. I'm pretty much fluent in reading D mangled names by now, but
 most newcomers definitely aren't.

 That, coupled with the absence of the typical source location
 information (IDE integration!), is probably enough to make encountering
 such errors a significantly more unpleasant experience for most people
 than compiler errors.

 Again, maybe not for you, maybe not for me, but I think it is clear that
 this is a problem to some, so the discussion should not be about talking
 the problem away, but rather about evaluating possible
 solutions/mitigation strategies in terms of feasibility (e.g. name
 demangling in linker output?).

 David



VisualD has a command line tool that demangels linker error messages and 
makes them more readable.

Kind Regards
Benjamin Thaut
Oct 28 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2012 2:38 PM, David Nadlinger wrote:

 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:

 It baffles me that programmers would find "undefined symbol" hard to make
 sense of.


 Do really think that your typical Java programmer is familiar with the term
 »symbol« in the compiler/linker sense?


I am baffled why a programmer with even a modest skill level in any language 
would not know what a symbol in a programming language is.



 Also, don't underestimate the perceived
 scariness/ugliness of mangled names in linker error messages. I'm pretty much
 fluent in reading D mangled names by now, but most newcomers definitely aren't.


I see the point of that, and at one point optlink did demangle names. But that 
didn't change anything. There was also a filter one could run the linker output 
through that would demangle the names, but nobody found that useful, either,
and 
it fell by the wayside.

You'll see the same complaints from the same people appearing for C code being 
linked, which does not have mangled names.



 That, coupled with the absence of the typical source location information (IDE
 integration!), is probably enough to make encountering such errors a
 significantly more unpleasant experience for most people than compiler errors.

 Again, maybe not for you, maybe not for me, but I think it is clear that this
is
 a problem to some, so the discussion should not be about talking the problem
 away, but rather about evaluating possible solutions/mitigation strategies in
 terms of feasibility (e.g. name demangling in linker output?).


There is this, which is linked to from the faq:

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

I even wrote an entry in this book

     http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484

about it. *Every* programmer should know what a linker does.
Oct 28 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-28 22:57, Walter Bright wrote:


 I am baffled why a programmer with even a modest skill level in any
 language would not know what a symbol in a programming language is.


Welcome to the real world :)


 I see the point of that, and at one point optlink did demangle names.
 But that didn't change anything. There was also a filter one could run
 the linker output through that would demangle the names, but nobody
 found that useful, either, and it fell by the wayside.

 You'll see the same complaints from the same people appearing for C code
 being linked, which does not have mangled names.


You still don't get any source location.



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


That's only for optlink.


 I even wrote an entry in this book


 http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484

 about it. *Every* programmer should know what a linker does.


I agree with you, but again, that's not the world we live in. On the 
other hand, why does, say, an PHP (insert your favorite dynamic 
programming language that doesn't use a linker) programmer need to know 
what a linker is?

-- 
/Jacob Carlborg
Oct 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 2:49 AM, Jacob Carlborg wrote:

 You'll see the same complaints from the same people appearing for C code
 being linked, which does not have mangled names.


 You still don't get any source location.


It's usually pretty obvious, but when it isn't, I use:

     grep -r symbol_name *.d

or whatever search function your IDE has.



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


 That's only for optlink.


True, but the suggestions for what to do next apply to any linker.



 *Every* programmer should know what a linker does.


 I agree with you, but again, that's not the world we live in. On the other
hand,
 why does, say, an PHP (insert your favorite dynamic programming language that
 doesn't use a linker) programmer need to know what a linker is?


Because it's a fundamental tool for programmers, despite PHP not using it. It's 
like knowing what a CPU register is.
Oct 29 2012
parent reply Faux Amis <faux amis.com> writes:
On 29/10/2012 18:38, Walter Bright wrote:

 On 10/29/2012 2:49 AM, Jacob Carlborg wrote:
  >> You'll see the same complaints from the same people appearing for C
 code
  >> being linked, which does not have mangled names.
  >
  > You still don't get any source location.

 It's usually pretty obvious, but when it isn't, I use:

      grep -r symbol_name *.d

 or whatever search function your IDE has.


  >>
 http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined
  >
  > That's only for optlink.

 True, but the suggestions for what to do next apply to any linker.


  >> *Every* programmer should know what a linker does.
  >
  > I agree with you, but again, that's not the world we live in. On the
 other hand,
  > why does, say, an PHP (insert your favorite dynamic programming
 language that
  > doesn't use a linker) programmer need to know what a linker is?

 Because it's a fundamental tool for programmers, despite PHP not using
 it. It's like knowing what a CPU register is.


Haha, I know a lot of professional programmers who do not know the 
difference between the stack and the heap but still are able to write 
useful code.
You really seem to be lurking way too much on newsgroups with 
knowledgeable people ;)
Oct 29 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 29, 2012 at 07:05:33PM +0100, Faux Amis wrote:

 On 29/10/2012 18:38, Walter Bright wrote:

On 10/29/2012 2:49 AM, Jacob Carlborg wrote:




[...]

 I agree with you, but again, that's not the world we live in. On
 the other hand, why does, say, an PHP (insert your favorite
 dynamic programming language that doesn't use a linker) programmer
 need to know what a linker is?


Because it's a fundamental tool for programmers, despite PHP not
using it. It's like knowing what a CPU register is.


 Haha, I know a lot of professional programmers who do not know the
 difference between the stack and the heap but still are able to write
 useful code.


The kind of code the average "professional" programmer produces is ...
shall I say, underwhelming? It's the kind of thing that makes me
consider career switches. Raising the bar for programmer qualification
will do the world a lot of good.


T

-- 
In theory, there is no difference between theory and practice.
Oct 29 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-29 20:00, H. S. Teoh wrote:


 The kind of code the average "professional" programmer produces is ...
 shall I say, underwhelming? It's the kind of thing that makes me
 consider career switches. Raising the bar for programmer qualification
 will do the world a lot of good.


Absolutely. The bar is not set very high.

-- 
/Jacob Carlborg
Oct 29 2012
prev sibling parent Faux Amis <faux amis.com> writes:
On 29/10/2012 20:00, H. S. Teoh wrote:

 On Mon, Oct 29, 2012 at 07:05:33PM +0100, Faux Amis wrote:

 On 29/10/2012 18:38, Walter Bright wrote:

 On 10/29/2012 2:49 AM, Jacob Carlborg wrote:




 [...]

 I agree with you, but again, that's not the world we live in. On
 the other hand, why does, say, an PHP (insert your favorite
 dynamic programming language that doesn't use a linker) programmer
 need to know what a linker is?


 Because it's a fundamental tool for programmers, despite PHP not
 using it. It's like knowing what a CPU register is.


 Haha, I know a lot of professional programmers who do not know the
 difference between the stack and the heap but still are able to write
 useful code.


 The kind of code the average "professional" programmer produces is ...
 shall I say, underwhelming? It's the kind of thing that makes me
 consider career switches. Raising the bar for programmer qualification
 will do the world a lot of good.


 T


I am not sure that less programmers would be a good thing for the world.

But, I have seen people who know all the ins and outs of their machine 
create horrible code which I will never allow to merge and people who 
barely know what a pointer is generate very clean, readable and usable 
code.
Oct 29 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-29 19:05, Faux Amis wrote:


 Haha, I know a lot of professional programmers who do not know the
 difference between the stack and the heap but still are able to write
 useful code.
 You really seem to be lurking way too much on newsgroups with
 knowledgeable people ;)


I completely agree. I can probably count the number of PHP developer who 
know what a CPU resister is on one hand. Let me add to that: Ruby, 
JavaScript, Python and a bunch of other languages.

-- 
/Jacob Carlborg
Oct 29 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-28 22:38, David Nadlinger wrote:


 Do really think that your typical Java programmer is familiar with the
 term »symbol« in the compiler/linker sense? Also, don't underestimate
 the perceived scariness/ugliness of mangled names in linker error
 messages. I'm pretty much fluent in reading D mangled names by now, but
 most newcomers definitely aren't.

 That, coupled with the absence of the typical source location
 information (IDE integration!), is probably enough to make encountering
 such errors a significantly more unpleasant experience for most people
 than compiler errors.

 Again, maybe not for you, maybe not for me, but I think it is clear that
 this is a problem to some, so the discussion should not be about talking
 the problem away, but rather about evaluating possible
 solutions/mitigation strategies in terms of feasibility (e.g. name
 demangling in linker output?).


I completely agree. I can handle the mangled symbols as well but it 
would be much nicer with demangled symbols, source location and so on.

Just because I can read HTML I'm not surfing the web with "curl", I use 
a GUI browser that renders the HTML. It's much nicer that way.

-- 
/Jacob Carlborg
Oct 29 2012
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29-Oct-12 01:38, David Nadlinger wrote:

 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:

 It baffles me that programmers would find "undefined symbol" hard to
 make sense of.


 Do really think that your typical Java programmer is familiar with the
 term »symbol« in the compiler/linker sense? Also, don't underestimate
 the perceived scariness/ugliness of mangled names in linker error
 messages. I'm pretty much fluent in reading D mangled names by now, but
 most newcomers definitely aren't.


So true.


 That, coupled with the absence of the typical source location
 information (IDE integration!), is probably enough to make encountering
 such errors a significantly more unpleasant experience for most people
 than compiler errors.



 Again, maybe not for you, maybe not for me, but I think it is clear that
 this is a problem to some, so the discussion should not be about talking
 the problem away, but rather about evaluating possible
 solutions/mitigation strategies in terms of feasibility (e.g. name
 demangling in linker output?).


Indeed, when dmd works as a driver and invokes a linker can't it just 
pipe its output through ddemangle?

-- 
Dmitry Olshansky
Oct 29 2012
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:

 On 10/28/2012 1:34 PM, deadalnix wrote:

 As Andrei stated, the linker's native language is encrypted 
 klingon.


 It baffles me that programmers would find "undefined symbol" 
 hard to make sense of.


_D3yeah9whats82__T4soS36_D4hard4toFZv9__lambda1FNaNbNfiiZbVE3understand9about12this

;-)

Seriously though, it's irrelevant. The fact is a lot of 
programmers, especially new programmers or ones from programming 
languages that don't use linkers find link errors scary and 
confusing.

Pretending otherwise gets us nowhere.

Saying it baffles you why things are this way gets us nowhere.

Saying that "they should understand" gets us nowhere.
Oct 29 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/29/12 2:10 PM, Peter Alexander wrote:

 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:

 On 10/28/2012 1:34 PM, deadalnix wrote:

 As Andrei stated, the linker's native language is encrypted klingon.


 It baffles me that programmers would find "undefined symbol" hard to
 make sense of.


 _D3yeah9whats82__T4soS36_D4hard4toFZv9__lambda1FNaNbNfiiZbVE3understand9about12this


 ;-)

 Seriously though, it's irrelevant. The fact is a lot of programmers,
 especially new programmers or ones from programming languages that don't
 use linkers find link errors scary and confusing.

 Pretending otherwise gets us nowhere.

 Saying it baffles you why things are this way gets us nowhere.

 Saying that "they should understand" gets us nowhere.


I agree (and was about to post something very close to this). I've heard 
many times about this particular baffling, and it's one of those cases 
in which clearly people who are otherwise competent have quite a bit of 
difficulty. So one reasonable resolution is "well that's how people are, 
and that you think differently doesn't solve the matter one bit, so 
let's see what steps to take on improving it".

 From what I can tell here's how to solve linker error issues:

1. Automatic demangling of the symbols involved must be in place.

2. For undefined symbols, there must be reference at source file and 
line level of where they are referred - /all/ places!

3. For multiply defined symbols, there must be reference at source file 
and line level for each definition.

I understand there are technical difficulties in implementing the above, 
but that doesn't justify being baffled.

Being baffled is not an option.


Andrei
Oct 29 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-29 19:19, Andrei Alexandrescu wrote:


 I agree (and was about to post something very close to this). I've heard
 many times about this particular baffling, and it's one of those cases
 in which clearly people who are otherwise competent have quite a bit of
 difficulty. So one reasonable resolution is "well that's how people are,
 and that you think differently doesn't solve the matter one bit, so
 let's see what steps to take on improving it".

  From what I can tell here's how to solve linker error issues:

 1. Automatic demangling of the symbols involved must be in place.

 2. For undefined symbols, there must be reference at source file and
 line level of where they are referred - /all/ places!

 3. For multiply defined symbols, there must be reference at source file
 and line level for each definition.

 I understand there are technical difficulties in implementing the above,
 but that doesn't justify being baffled.

 Being baffled is not an option.


Well said.

-- 
/Jacob Carlborg
Oct 29 2012
prev sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Mon, 29 Oct 2012, Andrei Alexandrescu wrote:

 On 10/29/12 2:10 PM, Peter Alexander wrote:

 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
 
 Seriously though, it's irrelevant. The fact is a lot of programmers,
 especially new programmers or ones from programming languages that don't
 use linkers find link errors scary and confusing.
 
 Pretending otherwise gets us nowhere.
 
 Saying it baffles you why things are this way gets us nowhere.
 
 Saying that "they should understand" gets us nowhere.


 
 I agree (and was about to post something very close to this). I've heard many
 times about this particular baffling, and it's one of those cases in which
 clearly people who are otherwise competent have quite a bit of difficulty. So
 one reasonable resolution is "well that's how people are, and that you think
 differently doesn't solve the matter one bit, so let's see what steps to take
 on improving it".
 
 From what I can tell here's how to solve linker error issues:
 
 1. Automatic demangling of the symbols involved must be in place.
 
 2. For undefined symbols, there must be reference at source file and line
 level of where they are referred - /all/ places!
 
 3. For multiply defined symbols, there must be reference at source file and
 line level for each definition.
 
 I understand there are technical difficulties in implementing the above, but
 that doesn't justify being baffled.
 
 Being baffled is not an option.
 
 
 Andrei


There's another angle to this:

1) It's been stated more than once that one of the goals for D is to 
achieve a user base of over 1 million users.

2) I assert that there aren't more than 1 million programmers with the 
level of expertise and experience required to understand what happens 
during compilation to a sufficient degree that they feel comfortable with 
the tool chains that D (and c and c++) have today.

Conclusion, the tool chains must get more user friendly.
Oct 29 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/29/12, Brad Roberts <braddr puremagic.com> wrote:

 Conclusion, the tool chains must get more user friendly.


Yep. Just compare:

$ dmd -c test.d -oftest.obj

Optlink:
$ link test.obj

 test.obj(test)
  Error 42: Symbol Undefined _D4test1A3fooMFZv


Unilink:
$ ulink test.obj

 Error: Unresolved external 'test.A.foo()' referenced from 'test.obj'
Oct 29 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 1:19 PM, Brad Roberts wrote:

 There's another angle to this:

 1) It's been stated more than once that one of the goals for D is to
 achieve a user base of over 1 million users.

 2) I assert that there aren't more than 1 million programmers with the
 level of expertise and experience required to understand what happens
 during compilation to a sufficient degree that they feel comfortable with
 the tool chains that D (and c and c++) have today.

 Conclusion, the tool chains must get more user friendly.



Stroustrup estimates "more than 3 million" C++ users in 2004.

http://www.stroustrup.com/bs_faq.html#number-of-C++-users

There are probably more than that many C users.
Oct 29 2012
next sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Mon, 29 Oct 2012, Walter Bright wrote:


 On 10/29/2012 1:19 PM, Brad Roberts wrote:

 There's another angle to this:

 1) It's been stated more than once that one of the goals for D is to
 achieve a user base of over 1 million users.

 2) I assert that there aren't more than 1 million programmers with the
 level of expertise and experience required to understand what happens
 during compilation to a sufficient degree that they feel comfortable with
 the tool chains that D (and c and c++) have today.

 Conclusion, the tool chains must get more user friendly.


 
 
 Stroustrup estimates "more than 3 million" C++ users in 2004.
 
 http://www.stroustrup.com/bs_faq.html#number-of-C++-users
 
 There are probably more than that many C users.


Think there's any chance that 1/3 of the existing c++ users are going to 
switch to d?  In the next year?  Me neither.

The majority of D users are newish developers or developers w/out history 
in the C style compilation model.  It's just foreign and the majority 
aren't interested in having to learn about issues that the higher level 
languages don't require.

It's friction.  It needs to be reduced.

I say all of the above having been essentially an member of the C style 
compilation model, exclusively.
Oct 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 3:11 PM, Brad Roberts wrote:

 It's friction.  It needs to be reduced.


Short of building the linking code into dmd, the options are fairly limited.

Note that I did build the librarian code into dmd, instead of leaving it as a 
separate utility (lib.exe, ar), and have been pretty pleased with the results. 
But the librarian is a trivial piece of code.
Oct 29 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/29/12 6:13 PM, Walter Bright wrote:

 On 10/29/2012 3:11 PM, Brad Roberts wrote:

 It's friction. It needs to be reduced.


 Short of building the linking code into dmd, the options are fairly
 limited.


Why can't the linking code be built into dmd? I am baffled :o).

Andrei
Oct 29 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 Why can't the linking code be built into dmd? I am baffled :o).


This is possible, but a better question is how much work is 
required to do  this?

Walter was very slowly translating the current linker from 
disassembly to C. If and once that program is all C, it's 
probably not too much hard to convert it to D, merge it with the 
dmd binary, and improve it in some ways.

Bye,
bearophile
Oct 29 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, October 30, 2012 01:45:31 bearophile wrote:

 Andrei Alexandrescu:

 Why can't the linking code be built into dmd? I am baffled :o).


 
 This is possible, but a better question is how much work is
 required to do this?
 
 Walter was very slowly translating the current linker from
 disassembly to C. If and once that program is all C, it's
 probably not too much hard to convert it to D, merge it with the
 dmd binary, and improve it in some ways.


Depending, it should be fairly easy to just wrap the linker call and have dmd 
process its output and present something saner when there's an error. That 
could be a bit fragile though, since it would likely depend on the exact 
formatting of linker error messages. Better integration than that could be 
quite a bit more work.

I think that it's fairly clear that in the long run, we want something like 
this, but I don't know if it's worth doing right now or not.

- Jonathan M Davis
Oct 29 2012
prev sibling next sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Tue, 30 Oct 2012, bearophile wrote:

 Andrei Alexandrescu:
 

 Why can't the linking code be built into dmd? I am baffled :o).


 
 This is possible, but a better question is how much work is required to do
 this?
 
 Walter was very slowly translating the current linker from disassembly to C.
 If and once that program is all C, it's probably not too much hard to convert
 it to D, merge it with the dmd binary, and improve it in some ways.
 
 Bye,
 bearophile


Built in?  Absolutely not.  There's no way that it's architectually wise 
to have the linker as a part of the compiler binary.

Able to usefully interact with the linker?  Absolutely.

To be clear, I'm certain that Andrei was kidding / making a joke at 
Walter's expense.
Oct 29 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Brad Roberts:


 To be clear, I'm certain that Andrei was kidding / making a 
 joke at Walter's expense.


Oh, I see, I have missed the joke again, sorry :-)

Bye,
bearophile
Oct 29 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 6:43 PM, Brad Roberts wrote:

 To be clear, I'm certain that Andrei was kidding / making a joke at
 Walter's expense.



Andrei never jokes about programming :-)
Oct 29 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/29/12 10:57 PM, Walter Bright wrote:

 On 10/29/2012 6:43 PM, Brad Roberts wrote:

 To be clear, I'm certain that Andrei was kidding / making a joke at
 Walter's expense.



 Andrei never jokes about programming :-)


The question was fair. The "backatcha" baffling was one of my better 
jokes. Well I have my moments.

Andrei
Oct 29 2012
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On Tue, 30 Oct 2012, Jonathan M Davis wrote:

 On Tuesday, October 30, 2012 01:45:31 bearophile wrote:

 Andrei Alexandrescu:

 Why can't the linking code be built into dmd? I am baffled :o).


 
 This is possible, but a better question is how much work is
 required to do this?
 
 Walter was very slowly translating the current linker from
 disassembly to C. If and once that program is all C, it's
 probably not too much hard to convert it to D, merge it with the
 dmd binary, and improve it in some ways.


 
 Depending, it should be fairly easy to just wrap the linker call and have dmd 
 process its output and present something saner when there's an error. That 
 could be a bit fragile though, since it would likely depend on the exact 
 formatting of linker error messages. Better integration than that could be 
 quite a bit more work.
 
 I think that it's fairly clear that in the long run, we want something like 
 this, but I don't know if it's worth doing right now or not.
 
 - Jonathan M Davis


 
If someone wants to work on it, I'm sure no one would stop them.  In fact, 
someone did a specific case already.

But for the Top Men to engage on?  Almost certainly not.

I was working on "recognize that there's room for improvement" and 
"improvement is important for adoption" not "get working on it now".

--

If someone wanted to take on an ambitious task, one of the key problems 
with output munging is the parseability of the output (which applies to 
the compiler, linker, etc.. all the compiler chain tools).  Few (none?) of 
them output text that's designed for parsability (though some make it 
relatively easy).  It would be interesting to design a structured format 
and write scripts to sit between the various components to handle adapting 
the output.

Restated via an example:

today:
  compiler invokes tools and just passes on output

ideal (_an_ ideal, don't nitpick):
  compiler invokes tool which returns structured output and uses that

intermediate that's likely easier to achieve:
  compiler invokes script that invokes tool (passing args) and fixes 
output to match structured output

pro:
 + compiler only needs to understand one format
 + one script per tool (also a con, but on the pro side, each script is 
focused in what it needs to understand and care about)
 + no need to tear into each tool to restructure it's i/o code

cons:
 - will likely force some form of lowest common denominator
 - more overhead due to extra parsing and processes

I used the term script, but don't read much into that, just implying that 
it's small and doesn't have to do much.

Now that I've written it up.. might actually be fun to do, but I've got 
too many in-flight projects as it is, so I'll resist starting on it.

Later,
Brad
Oct 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-30 02:58, Brad Roberts wrote:


 If someone wanted to take on an ambitious task, one of the key problems
 with output munging is the parseability of the output (which applies to
 the compiler, linker, etc.. all the compiler chain tools).  Few (none?) of
 them output text that's designed for parsability (though some make it
 relatively easy).  It would be interesting to design a structured format
 and write scripts to sit between the various components to handle adapting
 the output.

 Restated via an example:

 today:
    compiler invokes tools and just passes on output

 ideal (_an_ ideal, don't nitpick):
    compiler invokes tool which returns structured output and uses that

 intermediate that's likely easier to achieve:
    compiler invokes script that invokes tool (passing args) and fixes
 output to match structured output


Even better, in my opinion: Both the linker and compiler is built as a 
library. The compiler just calls a function from the linker library, 
like any other function, to do the linking. The linker uses the 
appropriate exception handling mechanism as any other function would. No 
need for tools calling each other and parsing output data.

-- 
/Jacob Carlborg
Oct 30 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 30, 2012 at 09:51:34AM +0100, Jacob Carlborg wrote:

 On 2012-10-30 02:58, Brad Roberts wrote:


[...]

today:
   compiler invokes tools and just passes on output

ideal (_an_ ideal, don't nitpick):
   compiler invokes tool which returns structured output and uses that

intermediate that's likely easier to achieve:
   compiler invokes script that invokes tool (passing args) and fixes
output to match structured output


=20
 Even better, in my opinion=10: Both the linker and compiler is built
 as a library. The compiler just calls a function from the linker
 library, like any other function, to do the linking. The linker uses
 the appropriate exception handling mechanism as any other function
 would. No need for tools calling each other and parsing output data.


[...]

+1. This is 2012, we have developed the concept of libraries, why are we
still trying to parse output between two tools (compiler & linker) that
are so closely intertwined? Not the mention the advantages of having the
compiler and linker as a library: reusability in IDEs, adaptability to
*runtime* compilation, and a host of other powerful usages.


T

--=20
"A one-question geek test. If you get the joke, you're a geek: Seen on a Ca=
lifornia license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - N=
atural Intelligence, Inc.
Oct 30 2012
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 10/30/2012 7:46 AM, H. S. Teoh wrote:

 On Tue, Oct 30, 2012 at 09:51:34AM +0100, Jacob Carlborg wrote:

 On 2012-10-30 02:58, Brad Roberts wrote:


 [...]

 today:
   compiler invokes tools and just passes on output

 ideal (_an_ ideal, don't nitpick):
   compiler invokes tool which returns structured output and uses that

 intermediate that's likely easier to achieve:
   compiler invokes script that invokes tool (passing args) and fixes
 output to match structured output


 Even better, in my opinion: Both the linker and compiler is built
 as a library. The compiler just calls a function from the linker
 library, like any other function, to do the linking. The linker uses
 the appropriate exception handling mechanism as any other function
 would. No need for tools calling each other and parsing output data.


 [...]
 
 +1. This is 2012, we have developed the concept of libraries, why are we
 still trying to parse output between two tools (compiler & linker) that
 are so closely intertwined? Not the mention the advantages of having the
 compiler and linker as a library: reusability in IDEs, adaptability to
 *runtime* compilation, and a host of other powerful usages.
 
 
 T
 


I'm all for idealistic views, but neither of those matches reality in any
meaningful way.  What I outlined is actually
practical.
Oct 30 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-30 18:34, Brad Roberts wrote:


 I'm all for idealistic views, but neither of those matches reality in any
meaningful way.  What I outlined is actually
 practical.


Well yes, for an already existing tool. But I see no reason why one 
wouldn't use this approach when developing a new tool. Lately, all my 
tools I write are built as libraries and a fairly thin executable that 
calls the library. Except that one can use the library in other tools it 
separates and modularize the code, easier to test and so on.

-- 
/Jacob Carlborg
Oct 30 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 30, 2012 at 08:55:26PM +0100, Jacob Carlborg wrote:

 On 2012-10-30 18:34, Brad Roberts wrote:
 

I'm all for idealistic views, but neither of those matches reality in
any meaningful way.  What I outlined is actually practical.


 
 Well yes, for an already existing tool. But I see no reason why one
 wouldn't use this approach when developing a new tool. Lately, all
 my tools I write are built as libraries and a fairly thin executable
 that calls the library. Except that one can use the library in other
 tools it separates and modularize the code, easier to test and so
 on.


[...]

I have recently come to the conclusion that *all* programs should be
written as (potential) libraries with thin executable wrappers. Any
other approach will suffer from reusability issues down the road.


T

-- 
One Word to write them all, One Access to find them, One Excel to count
them all, And thus to Windows bind them. -- Mike Champion
Oct 30 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 4:37 PM, Andrei Alexandrescu wrote:> On 10/29/12 6:13 PM, Walter 
Bright wrote:

 On 10/29/2012 3:11 PM, Brad Roberts wrote:

 It's friction. It needs to be reduced.


 Short of building the linking code into dmd, the options are fairly
 limited.


 Why can't the linking code be built into dmd? I am baffled :o).


No need for :o), it's a fair question.

The linking process itself is pretty simple. The problems come from designers 
who can't resist making things as complicated as possible. Just look at the 
switches for the various linkers, and what they purport to do. Then, look at
all 
the complicated file formats it deals with:

res files
def files
linker script files
dwarf
codeview
magic undocumented formats
pe files
shared libraries
eh formats

And that's just the start.
Oct 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-30 03:48, Walter Bright wrote:


 No need for :o), it's a fair question.

 The linking process itself is pretty simple. The problems come from
 designers who can't resist making things as complicated as possible.
 Just look at the switches for the various linkers, and what they purport
 to do. Then, look at all the complicated file formats it deals with:

 res files
 def files
 linker script files
 dwarf
 codeview
 magic undocumented formats
 pe files
 shared libraries
 eh formats

 And that's just the start.


The linker should not be directly built into the compiler. It should be 
build as a library, like the rest of the tool chain. The compiler then 
calls a function in the linker library to do the linking.

See one of my other replies:

http://forum.dlang.org/thread/jxiupltnfbmbvyxherca forum.dlang.org?page=5#post-k6o4en:242bld:241:40digitalmars.com

-- 
/Jacob Carlborg
Oct 30 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 30 October 2012 at 08:53:49 UTC, Jacob Carlborg wrote:

 On 2012-10-30 03:48, Walter Bright wrote:


 No need for :o), it's a fair question.

 The linking process itself is pretty simple. The problems come 
 from
 designers who can't resist making things as complicated as 
 possible.
 Just look at the switches for the various linkers, and what 
 they purport
 to do. Then, look at all the complicated file formats it deals 
 with:

 res files
 def files
 linker script files
 dwarf
 codeview
 magic undocumented formats
 pe files
 shared libraries
 eh formats

 And that's just the start.


 The linker should not be directly built into the compiler. It 
 should be build as a library, like the rest of the tool chain. 
 The compiler then calls a function in the linker library to do 
 the linking.

 See one of my other replies:

 http://forum.dlang.org/thread/jxiupltnfbmbvyxherca forum.dlang.org?page=5#post-k6o4en:242bld:241:40digitalmars.com


This is most likely the approach taken by Delphi and .NET.
Oct 30 2012
prev sibling parent Faux Amis <faux amis.com> writes:
On 29/10/2012 22:34, Walter Bright wrote:

 On 10/29/2012 1:19 PM, Brad Roberts wrote:
  > There's another angle to this:
  >
  > 1) It's been stated more than once that one of the goals for D is to
  > achieve a user base of over 1 million users.
  >
  > 2) I assert that there aren't more than 1 million programmers with the
  > level of expertise and experience required to understand what happens
  > during compilation to a sufficient degree that they feel comfortable
 with
  > the tool chains that D (and c and c++) have today.
  >
  > Conclusion, the tool chains must get more user friendly.


 Stroustrup estimates "more than 3 million" C++ users in 2004.

 http://www.stroustrup.com/bs_faq.html#number-of-C++-users

 There are probably more than that many C users.


In 2004 C++ was on the top of its game.
http://www.tiobe.com/content/paperinfo/tpci/C__.html

But, I also think 1 million is on the low side. It is probably closer to 
5 (third=C,C++,alike of 15) million, excluding the "feel comfortable" 
part of course.
http://stackoverflow.com/questions/453880/how-many-developers-are-there-in-the-world

I also wanted to say some thing about expectations and reasons to switch..
Oct 29 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 28/10/2012 21:59, Walter Bright a écrit :

 On 10/28/2012 1:34 PM, deadalnix wrote:

 As Andrei stated, the linker's native language is encrypted klingon.


 It baffles me that programmers would find "undefined symbol" hard to
 make sense of.


Undefined symbol is the clear part of the message.

The mangled madness that follow that is supposed to help finding what 
symbol we are dealing with is the unclear part.

Not to mention ddemangle is unable to demangle many D mangling.
Oct 30 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 30, 2012 at 12:22:15PM +0100, deadalnix wrote:

 Le 28/10/2012 21:59, Walter Bright a écrit :

On 10/28/2012 1:34 PM, deadalnix wrote:

As Andrei stated, the linker's native language is encrypted klingon.


It baffles me that programmers would find "undefined symbol" hard to
make sense of.


 
 Undefined symbol is the clear part of the message.
 
 The mangled madness that follow that is supposed to help finding
 what symbol we are dealing with is the unclear part.
 
 Not to mention ddemangle is unable to demangle many D mangling.


Yeah, what's up with that? I looked briefly at the code, and there's a
comment that says that it only demangles a certain subset of symbols
because the others are "useless" when it comes to ABI's, or something
like that. I have no idea what that means and why it matters. What's
wrong with demangle() demangling *everything*? Isn't that what it's
supposed to be doing anyway?


T

-- 
The early bird gets the worm. Moral: ewww...
Oct 30 2012
prev sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Sunday, 28 October 2012 at 13:39:26 UTC, bearophile wrote:

 This code compiles with no errors, and then later the linker 
 gives a "Symbol Undefined":


 abstract class A {
     public void foo();
 }
 class B : A {}
 void main() {}


Interestingly, adding abstract to the method will result in no 
linker error for compiling. And if a new B is created then a 
compiler error is provided instead of a linker error.

I'm for getting some line numbers over the less informative 
linker error.
Oct 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 2:28 PM, Jesse Phillips wrote:

 On Sunday, 28 October 2012 at 13:39:26 UTC, bearophile wrote:

 This code compiles with no errors, and then later the linker gives a "Symbol
 Undefined":


 abstract class A {
     public void foo();
 }
 class B : A {}
 void main() {}


 Interestingly, adding abstract to the method will result in no linker error for
 compiling.


That's because by saying "abstract" you're telling the compiler that there is
no 
implementation for A.foo(), which is fundamentally different from saying that 
A.foo() is defined elsewhere. The compiler inserts a 0 in the vtbl[] slot for 
it, even though it won't let you try to call it.


 And if a new B is created then a compiler error is provided instead
 of a linker error.


Abstract types are really a different thing from "it's defined somewhere else."


 I'm for getting some line numbers over the less informative linker error.


The object file format does not support line numbers for symbol references and 
definitions. None of the 4 supported ones (OMF, ELF, Mach-O, MsCoff) have that. 
Even the symbolic debug info doesn't have line numbers for references, just for 
definitions.
Oct 29 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:k6mun3$a8h$1 digitalmars.com...

 The object file format does not support line numbers for symbol references 
 and definitions. None of the 4 supported ones (OMF, ELF, Mach-O, MsCoff) 
 have that. Even the symbolic debug info doesn't have line numbers for 
 references, just for definitions.


While this is true, you could scan the relocations for matching symbols, 
then use the debug information to get line numbers.  This would work for all 
function calls at least.
Oct 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 9:51 PM, Daniel Murphy wrote:> "Walter Bright" 
<newshound2 digitalmars.com> wrote in message

 news:k6mun3$a8h$1 digitalmars.com...

 The object file format does not support line numbers for symbol references
 and definitions. None of the 4 supported ones (OMF, ELF, Mach-O, MsCoff)
 have that. Even the symbolic debug info doesn't have line numbers for
 references, just for definitions.


 While this is true, you could scan the relocations for matching symbols,
 then use the debug information to get line numbers.  This would work for all
 function calls at least.



If the symbol is undefined, then there is no debug info for it.
Oct 29 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:k6npgi$1hsr$1 digitalmars.com...

 On 10/29/2012 9:51 PM, Daniel Murphy wrote:> "Walter Bright" 
 <newshound2 digitalmars.com> wrote in message

 news:k6mun3$a8h$1 digitalmars.com...

 The object file format does not support line numbers for symbol 
 references
 and definitions. None of the 4 supported ones (OMF, ELF, Mach-O, 
 MsCoff)
 have that. Even the symbolic debug info doesn't have line numbers for
 references, just for definitions.


 While this is true, you could scan the relocations for matching symbols,
 then use the debug information to get line numbers.  This would work for 
 all
 function calls at least.



 If the symbol is undefined, then there is no debug info for it.


There will be debug information for the call site if it is in the user's 
program.

eg

void foo();

void main()
{
   foo();
}


dmd testx -g


DMD v2.061 DEBUG
OPTLINK (R) for Win32  Release 8.00.12
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
testx.obj(testx)
 Error 42: Symbol Undefined _D5testx3fooFZv
--- errorlevel 1


objconv -dr testx.obj


Dump of file: testx.obj, type: OMF32
Checksums are zero

LEDATA, LIDATA, COMDAT and FIXUPP records:
  LEDATA: segment $$SYMBOLS, Offset 0x0, Size 0x4B
  FIXUPP:
   Direct farword 32+16 bit, Offset 0x30, group FLAT. Symbol __Dmain (T6), 
inlin
e 0x0:0x0
  COMDAT: name , Offset 0x0, Size 0xD, Attrib 0x00, Align 0, Type 0, Base 0
  FIXUPP:
   Relatv 32 bit, Offset 0x4, group FLAT. Symbol _D5testx3fooFZv (T6), 
inline 0x
1000E
  LEDATA: segment _DATA, Offset 0x0, Size 0xE
  LEDATA: segment FM, Offset 0x0, Size 0x4
  FIXUPP:
   Direct 32 bit, Offset 0x0, group FLAT. Segment _DATA (T4), inline 0x0
  LEDATA: segment $$TYPES, Offset 0x0, Size 0x16

The FIXUPP record gives Offset 0x4 for the address _D5testx3fooFZv, and the 
debug information for main will give the line number of that offset.

I wouldn't want to implement it in assembly though.
Oct 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 11:08 PM, Daniel Murphy wrote:

 void foo();


There will be no line information for the above.


 void main()
 {
    foo();


For this, yes, but that is not what is being asked for.
Oct 30 2012
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:k6o0fd$25mm$1 digitalmars.com...

 On 10/29/2012 11:08 PM, Daniel Murphy wrote:

 void foo();


 There will be no line information for the above.


 void main()
 {
    foo();


 For this, yes, but that is not what is being asked for.


It isn't?  Oops, my bad.
Oct 30 2012
prev sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Tuesday, 30 October 2012 at 07:43:41 UTC, Walter Bright wrote:

 On 10/29/2012 11:08 PM, Daniel Murphy wrote:

 void foo();


 There will be no line information for the above.


 void main()
 {
    foo();


 For this, yes, but that is not what is being asked for.


Well, personally I think I would enjoy having this line number. 
The more information the better.
Oct 30 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/12 2:13 PM, Jesse Phillips wrote:

 On Tuesday, 30 October 2012 at 07:43:41 UTC, Walter Bright wrote:

 On 10/29/2012 11:08 PM, Daniel Murphy wrote:

 void foo();


 There will be no line information for the above.


 void main()
 {
 foo();


 For this, yes, but that is not what is being asked for.


 Well, personally I think I would enjoy having this line number. The more
 information the better.


Not sure I'm following but essentially if foo() is undefined the most 
interesting file/line references would be for all calls to foo(). The 
lines declaring foo() are nice to have but much less interesting.

Andrei
Oct 30 2012
parent reply Brad Roberts <braddr puremagic.com> writes:
On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:


 On 10/30/12 2:13 PM, Jesse Phillips wrote:

 On Tuesday, 30 October 2012 at 07:43:41 UTC, Walter Bright wrote:

 On 10/29/2012 11:08 PM, Daniel Murphy wrote:

 void foo();


 
 There will be no line information for the above.
 

 void main()
 {
 foo();


 
 For this, yes, but that is not what is being asked for.


 
 Well, personally I think I would enjoy having this line number. The more
 information the better.


 
 Not sure I'm following but essentially if foo() is undefined the most
 interesting file/line references would be for all calls to foo(). The lines
 declaring foo() are nice to have but much less interesting.
 
 Andrei


I don't think I agree.  The key questions that come to mind from an 
undefined symbol error at link time are:

1) Why did the compiler believe it would be?  If it didn't think it was a 
valid usable symbol, it would have already errored at the call site during 
semantic analysis.

2) what's the fully qualified name of the symbol?  Maybe the compiler is 
matching a different symbol than expected.  However, if that was the case, 
either it'd link against the unexpected match successfully, or see also 



Having the location of some or all of the call sites might help you find
Oct 30 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/12 5:07 PM, Brad Roberts wrote:

 On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:


 On 10/30/12 2:13 PM, Jesse Phillips wrote:

 On Tuesday, 30 October 2012 at 07:43:41 UTC, Walter Bright wrote:

 On 10/29/2012 11:08 PM, Daniel Murphy wrote:

 void foo();


 There will be no line information for the above.


 void main()
 {
 foo();


 For this, yes, but that is not what is being asked for.


 Well, personally I think I would enjoy having this line number. The more
 information the better.


 Not sure I'm following but essentially if foo() is undefined the most
 interesting file/line references would be for all calls to foo(). The lines
 declaring foo() are nice to have but much less interesting.

 Andrei


 I don't think I agree.  The key questions that come to mind from an
 undefined symbol error at link time are:

 1) Why did the compiler believe it would be?  If it didn't think it was a
 valid usable symbol, it would have already errored at the call site during
 semantic analysis.


Not getting this at all. All I'm saying is that if the compiler says "I 
can't find that foo() you're asking for", the most interesting piece of 
information for me is "where did I ask for it?"


 2) what's the fully qualified name of the symbol?  Maybe the compiler is
 matching a different symbol than expected.  However, if that was the case,
 either it'd link against the unexpected match successfully, or see also



That's in the symbol.


Andrei
Oct 30 2012
parent reply Brad Roberts <braddr puremagic.com> writes:
On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:


 On 10/30/12 5:07 PM, Brad Roberts wrote:

 1) Why did the compiler believe it would be?  If it didn't think it was a
 valid usable symbol, it would have already errored at the call site during
 semantic analysis.


 
 Not getting this at all. All I'm saying is that if the compiler says "I can't
 find that foo() you're asking for", the most interesting piece of information
 for me is "where did I ask for it?"


Ok, so it points to a place in the code where you used it.  You look at 
that and say, yup, I did indeed use it.  Not surprising.  Now, why doesn't 
the linker find it?  Why did the compiler believe it existed?

The site of the usage isn't remotely useful for answering either of those 
questions and those are the ones that form the disconnect between the 
compiler, who believed it existed and let the code pass to the next 
stage), and the linker.
Oct 30 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/12 5:40 PM, Brad Roberts wrote:

 On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:


 On 10/30/12 5:07 PM, Brad Roberts wrote:

 1) Why did the compiler believe it would be?  If it didn't think it was a
 valid usable symbol, it would have already errored at the call site during
 semantic analysis.


 Not getting this at all. All I'm saying is that if the compiler says "I can't
 find that foo() you're asking for", the most interesting piece of information
 for me is "where did I ask for it?"


 Ok, so it points to a place in the code where you used it.  You look at
 that and say, yup, I did indeed use it.  Not surprising.


In the presence of overloading, that is most often surprising. And 
usually it's not "I" who uses it, it's transitively called by some code 
I write. That's the hardest part.


 Now, why doesn't
 the linker find it?


Because it's declared but not explicitly made part of the project.


 Why did the compiler believe it existed?


Grep takes care of that. Finding the declaration is never a problem.


 The site of the usage isn't remotely useful for answering either of those
 questions and those are the ones that form the disconnect between the
 compiler, who believed it existed and let the code pass to the next
 stage), and the linker.


Non-issue. Grep takes care of that. Finding the cross-references and the 
overloading part are the hard problems here. This is so clear to me for 
so many reasons, I am paralyzed by options.


Andrei
Oct 30 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2012 2:49 PM, Andrei Alexandrescu wrote:

 On 10/30/12 5:40 PM, Brad Roberts wrote:

 On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:


 On 10/30/12 5:07 PM, Brad Roberts wrote:

 1) Why did the compiler believe it would be?  If it didn't think it was a
 valid usable symbol, it would have already errored at the call site during
 semantic analysis.


 Not getting this at all. All I'm saying is that if the compiler says "I can't
 find that foo() you're asking for", the most interesting piece of information
 for me is "where did I ask for it?"


 Ok, so it points to a place in the code where you used it.  You look at
 that and say, yup, I did indeed use it.  Not surprising.


 In the presence of overloading, that is most often surprising. And usually it's
 not "I" who uses it, it's transitively called by some code I write. That's the
 hardest part.


 Now, why doesn't
 the linker find it?


 Because it's declared but not explicitly made part of the project.


 Why did the compiler believe it existed?


 Grep takes care of that. Finding the declaration is never a problem.


I find it ironic that you mention grep. Grep is what I suggested in the link to 
dealing with the issue, but nobody likes that answer.

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



 The site of the usage isn't remotely useful for answering either of those
 questions and those are the ones that form the disconnect between the
 compiler, who believed it existed and let the code pass to the next
 stage), and the linker.


 Non-issue. Grep takes care of that. Finding the cross-references and the
 overloading part are the hard problems here. This is so clear to me for so many
 reasons, I am paralyzed by options.


If you're missing a definition, you need to find the declaration, not the use, 
because that's where the missing definition needs to go.

And finally, grepping for an un-mangled name doesn't work for overloaded names.
Oct 30 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/12 6:00 PM, Walter Bright wrote:

 I find it ironic that you mention grep. Grep is what I suggested in the
 link to dealing with the issue, but nobody likes that answer.

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


Mangling is the issue here.


 The site of the usage isn't remotely useful for answering either of
 those
 questions and those are the ones that form the disconnect between the
 compiler, who believed it existed and let the code pass to the next
 stage), and the linker.


 Non-issue. Grep takes care of that. Finding the cross-references and the
 overloading part are the hard problems here. This is so clear to me
 for so many
 reasons, I am paralyzed by options.


 If you're missing a definition, you need to find the declaration, not
 the use, because that's where the missing definition needs to go.
 And finally, grepping for an un-mangled name doesn't work for overloaded
 names.


Upon more thinking, I agree that BOTH declarations and call sites must 
be clearly pointed in the errors output by the linker. But I'll still 
point out that the real difficulty is finding the calls, not the 
declarations. I don't ever remember having a hard time "where is this 
declared?" Instead, the hard problem has always been "What is the call 
chain that leads to an undefined symbol?"


Andrei
Oct 30 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 30, 2012 at 06:04:47PM -0400, Andrei Alexandrescu wrote:

 On 10/30/12 6:00 PM, Walter Bright wrote:


[...]

If you're missing a definition, you need to find the declaration, not
the use, because that's where the missing definition needs to go.
And finally, grepping for an un-mangled name doesn't work for
overloaded names.


 
 Upon more thinking, I agree that BOTH declarations and call sites must
 be clearly pointed in the errors output by the linker. But I'll still
 point out that the real difficulty is finding the calls, not the
 declarations. I don't ever remember having a hard time "where is this
 declared?" Instead, the hard problem has always been "What is the call
 chain that leads to an undefined symbol?"


[...]

You're forgetting the case where the symbol *is* defined, but you forgot
to include it in the list of source files to link. In that case, knowing
where the declaration is will tell you which source file you probably
forgot to add to the linker command line.


T

-- 
Life would be easier if I had the source code. -- YHL
Oct 30 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-30 22:49, Andrei Alexandrescu wrote:


 Non-issue. Grep takes care of that. Finding the cross-references and the
 overloading part are the hard problems here. This is so clear to me for
 so many reasons, I am paralyzed by options.


Assuming you have a fairly unique symbols in a quite small project. This 
where an IDE would be great to have. It could point to all the locations 
of the actual symbol, not just all text that matches the symbol.

-- 
/Jacob Carlborg
Oct 31 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/31/2012 12:39 AM, Jacob Carlborg wrote:> Assuming you have a fairly
unique 
symbols in a quite small project. This where

 an IDE would be great to have. It could point to all the locations of the
actual
 symbol, not just all text that matches the symbol.


Sure, but us long time command line users tend to write greppable names :-)
Oct 31 2012