Am Montag, den 11.02.2013, 14:09 +0100 schrieb Szabolcs Nagy:
> i've just tried it and the .a just got bigger
> and size reports minimal difference probably
> due to alignment differences, which does not matter
> 
> $ size libc.a.sections |awk '{s+=$4}END{print s}'
> 410638
> $ size libc.a |awk '{s+=$4}END{print s}'
> 410698

yes, for musl it probably isn't a big deal, because musl is basically
already divided in one compilation unit per function. As I said, the
only unused sections that drop out are those for the weak aliases that
finally have their real symbol linked in.

For other libraries that define weak symbols that are not needed later
this is more relevant. With P99 I have the opposite position to musl
(sort of). Everything are inline functions if possible (so they don't
even define a symbol) only some functions have to be weak because they
access to some static data or use setjmp. (P99 doesn't even have a
libp99.a or libp99.so file).

With the gc-section trick I can suck out the unused symbols from the
executable at the end.

> > The only real problem I have for libmusl.so is "environ", as of my
> > other patch. There is probably a good reason that this is made
> > weak. But why must it be realized as an alias? Wouldn't it be
> > sufficient to just have it as a weak symbol? something like
> > 
> > // implementation header file
> > extern char **__environ __attribute__((__weak ));
> > 
> > //__environ.c
> > char **environ __attribute__((__weak )) = 0;
> > weak_alias(environ, ___environ);
> > weak_alias(environ, __environ);
> > weak_alias(environ, _environ);
> > 
> 
> there are posix requirements for environ so it must be weak
> i'm not sure about the alias though

Anyhow the use of environ versus __environ was just not consistent
through the rest of musl. I have send another patch that should heal
that.

But thinking of it, I am not sure that the way that is done makes any
sense. If the reason to have environ weak is that the user code could
supply its own environ object, then the use of __environ all over musl
will certainly break things. Then environ and __environ could be two
different objects and the application code and musl would not be
consistent in their access to the environment.

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::