Re: [jamboost] Re: stage rule on windows problem

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-24 10:42:23

On Wednesday 24 November 2004 18:30, David Abrahams wrote:

> > Slightly offtopic, but this is a general issue with different versions of
> > software. MS decided that explicit export of symbols from DLL is a good
> > idea. Supposedly, they though it would be good for users.
>
> It is very good, in fact. If anyone got it "more right," I'd say it
> was MS in this case.

Ok, I did not try to say if it's good or bad.

> > And now we have a lot of problems because on windows there's no
> > declspec. Possible enhancement for one platform becomes portability
> > problem.
>
> Well, if only they hadn't made it so that no empty DLL can be built by
> their tools, it would be fine. I'm sure we could work around that in
> BBv2 by auto-generating an empty DLL when linking succeeds but
> produces no result.

You mean, producing an empty import LIB?

> > And the funny thing about this specific change is that gcc is adopting
> > the same model. Some development version have -fvisibility option which
> > can be used to change default symbols visibility to "hidden". An explicit
> > attribute on a class/function can be used to export a symbols. I'm not
> > sure how it happened, but probably this is somewhat affected by this
> > paper: http://www.ukuug.org/events/linux2002/papers/pdf/dsohowto.pdf, a
> > pretty complete overview of shared libs on Linux/ELF.
>
> It happened because of Niall Douglas, who got tired of waiting for
> long link times for Boost.Python extensions (and their large size).

Oh! And out of curiosity, what decrease in time/size is there for 
Boost.Python. KDE folks report about 5%, IIRC, but there are not as many 
templates.

- Volodya