[Xcb] hidden-visibility and library size

[Vincent Torri]

hey

I'm writing the hidden visibility support for xcb. I wanted to make it the
less intrusive possible in configure.ac, that is, i've written a macro for
it. Problem : with autoreconf, i'm not able to tell aclocal to look in any
dir where the macro is (in m4). I've added

AC_CONFIG_MACRO_DIR([m4])

at the beginning of configure.ac but it's seems that it's not sufficient.

The other solution is to put the code of the macro in configure.ac.
Another one is to not use autoreconf, but aclocal && autoconf &&
automake -a -c && libtoolize

What do you think ?

also, what do you think about adding a specific flag for debug ?

Vincent

On Sat, 24 Dec 2005, Vincent Torri wrote:

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