Dave wrote:
> Might want to take a look at the gcc '-s' switch as well. Man page (under gcc
> linking options):
> 
> -s  Remove all symbol table and relocation information from the executable.
> 
> It dramatically reduces the size of the executables on my system. Don't have
> much experience with it yet though.

I would rather that not be done automatically, as often the symbols are needed. I think the user can run strip afterwards anyway to get the same result.

Walter Bright wrote:
> Dave wrote:
>> Might want to take a look at the gcc '-s' switch as well. Man page (under gcc
>> linking options):
>>
>> -s  Remove all symbol table and relocation information from the executable.
>>
>> It dramatically reduces the size of the executables on my system. Don't have
>> much experience with it yet though.
> 
> I would rather that not be done automatically, as often the symbols are needed. I think the user can run strip afterwards anyway to get the same result.

Ok - just thought I'd throw that out there.

- Dave

Sean Kelly wrote:
> Dave wrote:
>> Sean Kelly wrote:
>>> Walter Bright wrote:
>>>>
>>>> BTW, internal\dmain2.d also uses printf to print out an error message relating to any uncaught exceptions.
>>>
>>> Ares currently uses fprintf for this purpose, which is essentially the same thing.  And as you say, it would be easy enough to hook the function if this behavior isn't desirable.
>>>
>>> I'm glad the compiler issues came to light however.  I don't suppose this will have any impact on the template code generation problem in libraries?
>>
>> Sean - could you point me to some links or post some example code on this?
> 
> http://svn.dsource.org/projects/ares/trunk/src/dmdrt/dmain2.d
> 
> See the "catch" blocks near the end of the file.
> 
> 
> Sean

I still don't understand in the context of this message - what are the error messages you're getting?

Thanks,

- Dave

Walter Bright wrote:
> This capability of linkers (eliminating unreferenced functions) first appeared in the late 80's, and quickly became standard practice. If you've got a linker that doesn't support that, you're likely to have many other serious problems with it, as D (and C++) depend on other linker features introduced in the late 80's.
> 
> D doesn't require anything of a linker that C++ doesn't already realistically require.

Last 3 years I had to use Microsoft linker (from VS98, VS2003) and it really foolish (especially if compared with DMC optimizing linker).

I fulfilled investigations and it seems MS linker uses "hungry" algorithm - it wants any extern symbol declared in module, even if it is not used, then walk though all objects in libs in search for those symbols; meanwhile it includes all data found in that objects. After this cycle,  /optref switch tries to drop unreferenced functions - but a lot of data get linked in anyway and sometimes this unnecessary data references a lot of code.
Most problems we had with static objects of virtual classes - when only existence of such object added references for all its virtual methods and so on.

The only solution against this awful linker strategy was to split modules into *very* small files and manually predict dependencies and try to prevent linker from wanting something that nobody else wants.
It was hard. For previous 3 years with DMC I never needed such handwork.

Digital Mars linker is great in this field, but you definitely cannot assume that all linkers sing late 80's are as smart as DMC.

Nic Tiger.

Nic Tiger wrote:
> Walter Bright wrote:
>> This capability of linkers (eliminating unreferenced functions) first appeared in the late 80's, and quickly became standard practice. If you've got a linker that doesn't support that, you're likely to have many other serious problems with it, as D (and C++) depend on other linker features introduced in the late 80's.
>>
>> D doesn't require anything of a linker that C++ doesn't already realistically require.
> Digital Mars linker is great in this field, but you definitely cannot assume that all linkers sing late 80's are as smart as DMC.

I must say I'm surprised that 15+ year old linker technology that is easy to implement and once upon a time was much discussed (idiotically dubbed 'smart linking') seems to have fallen by the wayside.

At least the linkers D uses (optlink and newer versions of ld) support it. Optlink does it by default, and ld via a badly underdocumented obscure switch.

Dave wrote:
> Sean Kelly wrote:
>> Dave wrote:
>>> Sean Kelly wrote:
>>>> Walter Bright wrote:
>>>>>
>>>>> BTW, internal\dmain2.d also uses printf to print out an error message relating to any uncaught exceptions.
>>>>
>>>> Ares currently uses fprintf for this purpose, which is essentially the same thing.  And as you say, it would be easy enough to hook the function if this behavior isn't desirable.
>>>>
>>>> I'm glad the compiler issues came to light however.  I don't suppose this will have any impact on the template code generation problem in libraries?
>>>
>>> Sean - could you point me to some links or post some example code on this?
>>
>> http://svn.dsource.org/projects/ares/trunk/src/dmdrt/dmain2.d
>>
>> See the "catch" blocks near the end of the file.
> 
> I still don't understand in the context of this message - what are the error messages you're getting?

Oops, I think I misunderstood.  Were you asking about the template link problems?  See this thread:

http://www.digitalmars.com/d/archives/digitalmars/D/23685.html


Sean

Walter Bright wrote:
> 
> I must say I'm surprised that 15+ year old linker technology that is easy to implement and once upon a time was much discussed (idiotically dubbed 'smart linking') seems to have fallen by the wayside.
> 
> At least the linkers D uses (optlink and newer versions of ld) support it. Optlink does it by default, and ld via a badly underdocumented obscure switch.

I think this is one cause of the confusion about how Optlink behaves. But I do think that it is quite reasonable to expect such behavior, much as one expects optimization features in compilers.


Sean

Walter Bright wrote:
> kris wrote:
> 
>> Yes, that's correct. But typeinfo is a rather rudimetary part of the language support. Wouldn't you agree? If I, for example, declare an array of 10 bytes (static byte[10]) then I'm bound over to import std.string ~ simply because TypeInfo_StaticArray wants to use std.string.toString(int), rather than the C library version of itoa() or a "low-level support" version instead.
> 
> 
> It has nothing to do with having a static byte[10] declaration. For the program:
> 
> void main()
> {
>     static byte[10] b;
> }
> 
> The only things referenced by the object file are _main, __acrtused_con, and __Dmain. You can verify this by running obj2asm on the output, which gives:

> 
> It's just not a big deal. Try the following:
> 
> extern (C) int printf(char* f, ...) { return 0; }
> 
> void main()
> {
>     static byte[10] b;
> }
> 
> and compare the difference in exe file sizes, with and without the printf stub.
> 
> 
>>> printf doesn't pull in the floating point library (I went to a lot of effort to make that so!). It does pull in the C IO library, which is very hard to not pull in (there always seems to be something referencing it). It shouldn't pull in the C wide character stuff. D's IO (writefln) will pull in C's IO anyway, so the only thing extra is the integer version of the specific printf code (about 4K).
>>
>> How can it convert %f, %g and so on if it doesn't use FP support at all? 
> 
> 
> It's magic! Naw, it's just that if you actually use floating point in a program, the compiler emits a special extern reference (to __fltused) which pulls in the floating point IO formatting code. Otherwise, it defaults to just a stub. Try it.
> 
>> Either way, it's not currently possible to build a D program without a swathe of FP support code,
>> printf,
>> the entire C IO package,
>> wide-char support,
>> and a whole lot more besides. I'd assumed the linked FP support was for printf, but perhaps it's for std.string instead? I've posted the linker maps (in the past) to illustrate exactly this.
> 
> 
> My point is that assuming what is pulled in by what is about as reliable as guessing where the bottlenecks in one's code is.