'loopback' test size increase of +200k! (serious name clashing)

[Ralf Corsepius]

Am Die, 2003-03-18 um 01.21 schrieb Till Straumann:
> Hi.
> 
> Here's some magic:
> 
> 'size' on the vanilla 'loopback' test yields (powerpc/shared BSP)
> 
> powerpc-rtems-size o-optimize/loopback.exe
>      text	   data	    bss	    dec	    hex	filename
>    309264	  11080	  23381	 343725	  53ead	o-optimize/loopback.exe
> 
> Then, I decide to do some slight modifications, i.e. I do some
> string manipulation in the 'init' task and I happen to use the
> newlib 'strlcpy()' function.
Why did you do this?

strlcpy is BSD proprietary and therefore I'd prefer using strncpy
instead (At present time, there is only one single place in rtems which
uses strlcpy, while there are many places using strncpy.)

>  To my great surprise,
> 
> powerpc-rtems-size o-optimize/loopback.exe
>      text	   data	    bss	    dec	    hex	filename
>    502237	  19260	  51777	 573274	  8bf5a	o-optimize/loopback.exe
> 
> the executable grew by more than 200k or ~70%!!
> 
> The reason for this is the poorly packaged 'ppp' package.
> It implements a couple of C-library routines (and enhancements)
> and puts those 'helpers' into the same files with other ppp
> code. This eventually triggers an avalanche of library dependencies.
> 
> The moral:
> 
> A) PLEASE keep add-on stuff like www, ppp, dosfs, etc. in SEPARATE
>      libraries.
>      Merging everything into one giant librtemsbsp.a is IMHO not a good
>      idea - librtemscpu/librtemsbsp should only contain the core packages
>      without bloat.
If these add-on are properly written, they won't be pulled-in into the
executables :-)

>      My personal impression is that there are quite some differences in
>      quality and style between the RTEMS core proper and some of the
>      add-ons and/or BSPs.
ACK, but pppd by far is not the worst.

>      If I don't use ppp or the webserver or ftp or networking or libblock,
>      I don't want to have to debug linker problems with any of those
>      components. If a piece from a library is missing, it's much easier
>      to figure out what library to add than figuring out what triggers
>      linking of unwanted parts of one huge library.
Hmm, I am not opposed to doing this, but I think separating them into
separate libs won't help. All you'd do is to avoid accicentially
linking-in symbols from these applications if _you_ have another
application which conflicts with them.

I could think about two different approaches: 
* Making each application a "*.rel" (But I am not sure if this would
work).
* Cleaning up the namespaces of these applications.

> B) FIX the ppp (and possibly other) packages.
>       o the ppp package defines (global) names prone to clashing like
>        'lock', 'line', 'magic', 'debug', 'modem', just to name a few.
> 
>         SUCH NAMES DONT BELONG INTO librtemsbsp.a !!!!
Agreed, but no reason for shouting ;)

If necessary, such symbols should be namespaced or static, IMHO.

>       o eliminate reimplementation of newlib stuff. If it is absolutely
>         necessary to provide a reimplementation,
This should never be necessary. 

If _really_ needed, we can extend cpukit/libcsupport or newlib, instead.
IMHO, good _application_ code however should never require such measures
and should be written in such a way that it applies
portable/standardized libc-calls, only.

>  put each routine in
>         a separate file and use weak alias magic
Definitely no: weak symbols are non-portable (To my knowledge they are
proprietary to GNU/elf.)

>  so the reimplementation
>         is only used if 'newlib' doesn't provide it already.
We can use autoconf magic instead.

Ralf