Lib change leads to larger executables

[John Reimer]

On Fri, 23 Feb 2007 13:54:33 -0800, Walter Bright wrote:

> John Reimer wrote:
>> optlink may just be the bane for D acceptance. And Tango gets the pitiful
>> opportunity of demonstrating why D is NOT ready for prime-time in the
>> commercial realm: the DM support tools it relies on are bogged down in
>> the past, reflecting D's lopsided existance on yet another level: a strong
>> language relying on a fragile, outdated, and poorly fit tool set.
> 
> Linux's ld exhibits the same behavior. Try compiling the 3 files here 
> according to the instructions below, and try different orderings adding 
> the object files to the librarian (ar). The same behavior as lib/optlink 
> results (using nm to see what symbols are placed into the resulting 
> executable).
> 
> ------------------- test.d --------------------
> import b;       // a is not imported
> 
> void foo(...) { }
> 
> void test(char[][] s)
> {
>      bbb2();
>      foo(s);
> }
> 
> void main()
> {
> }
> --------------------- a.d -------------------
> void xxx(...) { }
> 
> void aaa(char[][] s)
> {
>      xxx(s);
> }
> 
> void aaa2()             // never referenced nor imported 'bloat'
> {
> }
> -------------------- b.d ---------------------
> void yyy(...) { }
> 
> void bbb(char[][] s)
> {
>      yyy(s);
> }
> 
> void bbb2()
> {
> }
> -------------------- build 1 -------------------
> dmd -c a.d test.d
> dmd -c b.d
> rm foo.a
> ar -r foo.a a.o b.o     <= a comes before b
> dmd test.o foo.a
> nm test >log		<= aaa2() appears in executable
> -------------------- build 2 -------------------
> dmd -c a.d test.d
> dmd -c b.d
> rm foo.a
> ar -r foo.a b.o a.o     <= b comes before a
> dmd test.o foo.a
> nm test >log		<= aaa2() does not appear in executable
> ---------------------------------------------


True, you are correct about the same error being represented here. This
proves only that ld/ar and optlink/lib are on equal footing in this
specific case. optlink/lib/OMF however have so many problems in other
aspects that my opinion stands.  (one simple example: think 64-bit... dmd
tools have no footing)

Concerning the problem at hand:

D is not C.  Resolving symbols in C era was part of the business and
pretty much cause/effect.  Not so with D and its hidden implementation
details and duplicate symbols resulting from implementation of language
features.

That's why D is different; that's why jerry-wrigging old tools to a new
language and expecting developers to rely on these tools and fix
problems like they are C programmers is totally absurd. Even expert D users
are going to be confounded.  New users will be more lost than if they were
using C. That's bad publicity for D, no two ways about it.

What your example above actually points out is the specific weakness
in D's TypeInfo implementation such that linker/librarians are rendered
incapable of making sane choices.  Maybe it's not the linkers and
librarians fault since they are too stupid to really figure a resolution?
If not, then it must be the implementation's fault.

Two options?  Create new a new object file format, a new linker, and a new
librarian to suite D's evolving feature set.  Everyone will yell
"overkill", "that's a nasty amount of work", "I'm not gonna do it!", and
"How are we going to support C?"

If we /must/ go a jerry-rigging to old tools in the name of keeping
things simple (and keeping the faith with C), then perhaps the better
option is to rethink how TypeInfo is implemented and mold it to fit sanely
into the containers and tools available. Like I said, to expect
programmers to troubleshoot hidden operations -- how linker and librarian
operate with D symbols that are practically invisible from the programmers
perspective -- is absolutely nasty and mean.  :)

This /really/ needs to be addressed.  Let's stop
saying that the programmer needs to learn to deal with this.  This is
really just a way of ignoring a show-stopping issue for D.  D cannot afford
to turn it's back on it anymore (as it has for the last few years).  D has
to be progressive in more than just language features to make an impact in
this world.

-JJR