On Sat, Jun 20, 2009 at 11:35 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Robert Fraser wrote:
>>
>> I'm considering doing so since Optlink won't work with the debug build of one of my libraries (it's 22MB),
>
> Is this reported in bugzilla?

http://d.puremagic.com/issues/show_bug.cgi?id=424

He's not the only one.  Ask me, Tom S., eldar..

Jarrett Billingsley wrote:
> On Sat, Jun 20, 2009 at 11:35 PM, Walter
> Bright<newshound1@digitalmars.com> wrote:
>> Robert Fraser wrote:
>>> I'm considering doing so since Optlink won't work with the debug build of
>>> one of my libraries (it's 22MB),
>> Is this reported in bugzilla?
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=424
> 
> He's not the only one.  Ask me, Tom S., eldar..

1. Robert doesn't say if that is the issue or not.

2. The last comment in the bug report is a request for a reproducible test case. I need one.

On Sun, Jun 21, 2009 at 1:27 AM, Walter Bright<newshound1@digitalmars.com> wrote:
> Jarrett Billingsley wrote:
>>
>> On Sat, Jun 20, 2009 at 11:35 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>>>
>>> Robert Fraser wrote:
>>>>
>>>> I'm considering doing so since Optlink won't work with the debug build
>>>> of
>>>> one of my libraries (it's 22MB),
>>>
>>> Is this reported in bugzilla?
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=424
>>
>> He's not the only one.  Ask me, Tom S., eldar..
>
> 1. Robert doesn't say if that is the issue or not.

Fair enough, though I'm just speaking from experience here.  Large objects = lots of fixups = dead OPTLINK.

> 2. The last comment in the bug report is a request for a reproducible test case. I need one.

I've just posted one.

Jarrett Billingsley wrote:
> On Sun, Jun 21, 2009 at 1:27 AM, Walter
> Bright<newshound1@digitalmars.com> wrote:
>> 2. The last comment in the bug report is a request for a reproducible test
>> case. I need one.
> 
> I've just posted one.

Thank you.

Walter Bright wrote:
> Optlink does not discard unreference symbols, it just doesn't pull them in from the library. If it did always pull in everything from the library, then the minimum D executable size will be the size of Phobos.
> 
> Since that isn't happening, something else is happening with your code. I bet that those unreferenced symbols *are* being referenced. You can determine this by using the librarian to remove those 'unreferenced' symbols from Phobos, and then link, and see if there are any unresolved symbol error messages.

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.

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.

Hello Robert,

> 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.
> 

what is needed is a reference graph tool and .exe inspector tool.

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.

> >> What's up with all the negativity lately? Impatience?
> > 
> > Some people think D2 tries too much, and neglects the really important things at the same time. For example, D2 tries to solve the concurrency issue (which is a hot topic which makes D look good at sites like stackoverflow), while still relying on a 20 years old linker written in assembler.
> 
> So the better direction according to some is to stagnate language design for D2 so Walter Bright can reinvent the linker? So that years later when asked why D didn't do more for concurrency when it was needed, you'd have to reply: "well there wasn't any time to deal with such trivial issues, the language designer had to work on the toolchain."
> 
You are of course completely correct in this, but the question is,
can you do a new linker? I can't. There must be someone out there who can - please, please.

Robert Fraser wrote:
> Your explanation sounds likely, however it seems VS is discriminating on the per-symbol level...?

Let's say the C++ source file looks like:

----------------------------
int foo() { ... }
int bar() { ... }
----------------------------

it is compiled and put into a library. Your program references foo(). Pulling in the object module from the library that contains foo() also pulls in bar(), because bar() is in the same object module. If bar() references a bunch of other stuff, that gets pulled in, too.

VS may contain some scheme to split a source file into multiple object modules which prevents this.

Note that dmd will split a single source file into multiple object modules when you compile with -lib.