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.
