View mode: basic / threaded / horizontal-split · Log in · Help
June 21, 2009
Re: The proper case for D.
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..
June 21, 2009
Re: The proper case for D.
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.
June 21, 2009
Re: The proper case for D.
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.
June 21, 2009
Re: The proper case for D.
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.
June 21, 2009
Re: The proper case for D.
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.
June 21, 2009
Re: The proper case for D.
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.
June 21, 2009
Re: The proper case for D.
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.
June 21, 2009
Re: The proper case for D.
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.
June 21, 2009
Re: The proper case for D.
> >> 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.
June 21, 2009
Re: The proper case for D.
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.
1 2 3
Top | Discussion index | About this forum | D home