RFC: use of hidden_def/hidden_proto

sjhill at realitydiluted.com sjhill at realitydiluted.com
Fri Jan 6 15:36:19 UTC 2006


> I would want to begin using hidden_def/hidden_proto and related 
> lib*_hidden_* within uClibc as glibc(libc-symbols.h) does instead of the 
> current practice in uClibc that looks like:
> 
> attribute_hidden __func() {}
> strong_alias(__func,func)
> 
> and #define func __func at the top of the *.c files, where func is in use 
> (some of the __func prototypes that are used more than 5 times are defined 
> if possible in libc-internal.h and the users are changed from func to 
> __func within *.c)
> 
I like it. I have a lot of these to deal with for NPTL. It is why my
'compat' directory is still around.

SNIP

> Benefits:
>

SNIP

>
> 4. allows later easy switch to versioned lib support
>
Absolutely no ****ing way. The reason glibc is so bloated is because
of a lot of the versioned symbols and backwards compatibility cruft.
I will fight to the death against any type of symbol versioning or
versioned lib support. Might I remind our readers that uClibc is for
embedded systems i.e. focus on size first, then IMHO, functionality
and possibly compatibility with older stuff. Every release up to this
point stresses that you have to recompile your applications for the
new version. Unless Erik and/or others are changing the goals, there
should be no version support. Hopefully I miss understood you and I
am off base.

-Steve



More information about the uClibc mailing list