RE: Make the compiler only build static. . .

[ANDY KENNEDY <ANDY dot KENNEDY at adtran dot com>]

> Not in crosstool-NG, but you can configure uClibc to build only the
> static libraries.

Perhaps that is the key.

> 
> But beware. If you are really size-constrained, and you have many
> programs,
> then static linking could make your file system grow.

True, though there are only a dozen or so functions being called,
and most of these are __syscall() defined in the libs, so not much
there (for example, pthread_create()).  

> 
> If you have many programs on your file system, and those programs
> call many
> of the C libraryu functions, then those functiopns bodies will be
> duplicated
> into every program that uses it. Which will make your file system
> grow. Now,
> if you have a single program, then static linking could be a
> solution. YMMV.

Taking the BusyBox approach -- all the apps will have xxxx_main()
so that we can use a single binary -- thus we have no duplication
AND, we only have 4 apps and most share code ANYWAY, so the BB way
will reduce many bytes of shared code (I hope).

> 
> But there are other options.
> 
> For example, there is a script called mklibs that will scan your
> file system
> for every executable programs, list all UNDefined symbols in them,
> search
> for those symbols in every shared libraries. Then for each shared
> library,
> it will try to recreate that library from the static version, but
> only with
> the symbols listed before. Rince and repeat until there are no more
> any
> UNDefined symbols.

Field updates are the main reason for NOT doing something like
this.  I don't even want to go there ;).

> 
> Of course, if the static version of the library does not exist,
> then the
> shared library is used as-is, as there is no way to remove function
> bodies
> (or other objects, for that matters) from a shared library.
> 
> That way, you get the best of both worlds:
>  - space gained using shared libs
>  - space gained from including only required symbols
> 
> You can find a version of mklibs in different places: buildroot,
> debian...
> Google is your friend there...
> 
> I am also planning on adding such a script (perhaps mklibs itself)
> to
> crosstool-NG, along with populate.
> 
> Regards,
> Yann E. MORIN.

I'll try the "build only static libs" approach.  Thanks!

Andy

--
For unsubscribe information see http://sourceware.org/lists.html#faq