tooling quality and some random rant

[spir]

On 02/14/2011 06:54 PM, Steven Schveighoffer wrote:
> 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...

The "public" problem is not with the (admittedly very bad) error message in 
iself. The problem imo is that newcomers have high chances to stumble on this 
merroges (or points of similar friendliness) at the very start of their 
adventures with D, and thus think D tools just treat programmers that way, and 
the D community finds this just normal. Oops!

I would be happy dmd to assume the main func is supposed to be located in the 
very first module passed on the command-line, if this can help. What do you think?
	"Error: cannot find main() function in module 'app.d'."
(But this would not solve the case of /multiple/ mains, which happens to me 
several times a day, namely each time I have run an imported module's test 
suite separately ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com