tooling quality and some random rant

[Steven Schveighoffer]

On Sun, 13 Feb 2011 14:12:02 -0500, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> Vladimir Panteleev wrote:
>> On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright  
>> <newshound2 at digitalmars.com> wrote:
>>
>>> golgeliyele wrote:
>>>> I don't think C++ and gcc set a good bar here.
>>>
>>> Short of writing our own linker, we're a bit stuck with what ld does.
>>  That's not true. The compiler has knowledge of what symbols will be  
>> passed to the linker, and can display its own, much nicer error  
>> messages. I've mentioned this in our previous discussion on this topic.
>
> Not without reading the .o files passed to the linker, and the  
> libraries, and figuring out what would be pulled in from those  
> libraries. In essence, the compiler would have to become a linker.
>
> It's not impossible, but is a tremendous amount of work in order to  
> improve one error message, and one error message that generations of C  
> and C++ programmers are comfortable dealing with.

I'm not saying that this should be done and is worth the tremendous effort.

However, when linking a c++ app without a main, here is what I get:

/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/crt1.o: In function  
`_start':
(.text+0x18): undefined reference to `main'

When linking a d app without a main, we get:


/home/steves/dmd-2.051/linux/bin/../lib/libphobos2.a(dmain2_517_1a5.o): In  
function `_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x16):  
undefined reference to `_Dmain'
/home/steves/dmd-2.051/linux/bin/../lib/libphobos2.a(deh2_4e7_525.o): In  
function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x4):  
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc):  
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13):  
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x37):  
undefined reference to `_deh_end'
/home/steves/dmd-2.051/linux/bin/../lib/libphobos2.a(thread_eb_258.o): In  
function `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):  
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):  
undefined reference to `_tlsstart'
/home/steves/dmd-2.051/linux/bin/../lib/libphobos2.a(thread_ee_6e4.o): In  
function `thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0x53): undefined reference to  
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0x5c): undefined reference to  
`_tlsend'
/home/steves/dmd-2.051/linux/bin/../lib/libphobos2.a(thread_e8_713.o): In  
function `thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x29): undefined reference to  
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x2f): undefined reference to  
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1

Let's not pretend that generations of c/C++ coders are going to attribute  
this slew of errors to a missing main function.  The first time I see  
this, I'm going to think I missed something else.

I understand that to fix this, we need the linker to be more helpful, or  
we need to make dmd more helpful.  I don't know how much effort it is, or  
how much it's worth it, I just wanted to point out that your statement  
about equivalence to C++ is stretching it.

I personally think we need to get the linker to demangle symbols better.   
That would go a long way...

-Steve