[Xcb] hidden-visibility and library size

[Vincent Torri]

On Sat, 24 Dec 2005, Jamey Sharp wrote:

> On Sat, Dec 24, 2005 at 11:36:58AM +0100, Vincent Torri wrote:
> > maybe we should try the hidden-visibility feature of gcc 4.*.
>
> I thought that feature was available in at least some 3.x versions too.

the first time I've seen that feature, it was avalaible as a patch for gcc
3.4.* (i don't remember the micro version number). Maybe it's avalaible in
the last 3.4.* gcc version (3.4.4 or 3.4.5). I don't know. But it's easy
to check that. I've done it with another project.

>
> > I've experienced a big decrease of the size of the libraries with
> > other projects.
>
> I've been meaning to do that to XCB's non-public functions, yeah.
> Besides code size reductions I gather there are benefits in application
> startup time during the dynamic linking process. So I'd love to get a
> patch.

ok, i'll try to make one, at least to test it in the configure script.

> Visibility doesn't help with any of the auto-generated code, though,
> because all of that code is public and uses only public XCB APIs.

it suffices to add XCBAPI before any exported function and define XCBAPI
according to whether the hidden visibility feature is avalaible or not.
But then, one should modify the xslt script.

> > Also, stripping the library can decrease its size too. I don't think
> > that we use it.
>
> That's more of a choice for distributors to make -- Debian, for example,
> automatically runs strip across all executables and libraries by
> default. Obviously running strip as part of the build process is not
> useful for us developers though, as it pretty much ruins debugging.

indeed. Of course when debugging, my thought is that ONLY -g (and warning
messages) must be used. No optimisation and stripping should be done in
debug mode.

Maybe adding a --enable-debug flag to configure, instead of
--with-opt=debug is more explicit

Also adding a --enale-strip flag too is perhaps a solution, at least to
make the user choose it or not.

> And my code-size measurements are always done using the `size` command,
> which reports only how big the text, data, and bss sections are --
> nothing about debugging symbols etc. So for the purposes of comparing
> memory footprint, we don't need to run strip.

As I'm talking about configure stuff, maybe one should add gprof and
valgrind support to xcb.

Vincent