The proper case for D.

[Robert Fraser]

Walter Bright wrote:
> Robert Fraser wrote:
>> Hmmm... well, I built a 3rd-party library (Platinum UPnP + Neptune) 
>> into two static libraries (with VS). I then wrote a C wrapper function 
>> around one, just to test out the functionality I needed (a fraction of 
>> what was available). Originally, I wanted to statically link it with 
>> my D project so I ran objconv on the libs (COFF -> OMF). I created a 
>> test D app that was basically just:
>>
>> extern(C) int cMain();
>> int main(char[][] args) { return cMain(); }
>>
>> ... And linked it to the OMF version of the library. Worked fine, but 
>> the result was ~12MB, which is about 200k larger than the two 
>> libraries. I'm now using VC++ to build it into a DLL that exposes the 
>> function. 802kb for a debug DLL, 280k for a release.
>>
>> The same thing is happening with my other library (ffmpeg -- 
>> libavcodec, libavformat, libavutil and swscale), which I built as 
>> static libraries with MinGW gcc and converted again with objconv. In 
>> this case, I'm too lazy to create a DLL to wrap only the functions I 
>> want, though I may end up doing just that once my project gets closer 
>> to usable.
> 
> It may be a problem with objconv where it puts everything into one obj 
> file.

Update on this -- I built it as a DLL in VS, exposing only the functions 
I need. The DLL is just under 5MB in release mode, and it took my main 
program down to 823k.

Your explanation sounds likely, however it seems VS is discriminating on 
the per-symbol level...? I'm going to need to make sure runtime CPU 
detection was still built in, though; VS may have been too smart for its 
own good.