Re: [Patches] Any remaining uses of option groups?

[OndÅej BÃlka <neleai@xxxxxxxxx>]

On Tue, Jun 18, 2013 at 10:23:14PM +0200, Abdoulaye Walsimou Gaye wrote:
> Hello,
> 
> On 06/13/2013 10:15 PM, Joseph S. Myers wrote:
> >My previous message removing a bitrotten and ill-conceived option group
> ><http://www.eglibc.org/archives/patches/msg01257.html> did not elicit any
> >responses expressing interest in option groups at all.  So, I now ask:
> >does anyone have a current use case for the option groups feature?  That
> >is, is there still any significant use of EGLIBC in building new embedded
> >GNU/Linux systems that are so space-constrained that the few MB taken up
> >by all the EGLIBC shared libraries put together is so significant that the
> >limited proportion of that space that can be saved through option groups
> >actually matters?
> 
> Please do not remove this still useful feature (including --disable-versioning),
> which makes embedded systems developers use eglibc rather than glibc.
> Yes even now days space matter. Many embedded systems do NOT have now
> days  smartphones specs.
> They usually have _less_ than 128MB of ram/32MB of ROM storage
> (and I worked on linux devices with less than that).
> How many time at work, we were requested to study reduction of BOM cost.
> Yes even 0.5$ of BOM cost down matter for an embedded system, and being
> able to reduce memory footprint helped a lot.

When you want to reduce memory footprint one argument is that you should
use generic solution. 

You could use tool that traverses system and looks for unused symbols in
all libraries and strips them. 

This might need to extend gcc to inform about dlsym(_,"CONSTANT") and 
dlsym(dlopen("library"), variable).

Second question is how this would play with libc plt avoidance.

Bit of googling found following which look to do that, it migth be useful.
http://libraryopt.sourceforge.net/ 


> On such systems, we do not care about about versioning, we upgrade all the
> system firmware at once, so yes --disable-versioning is useful.
>
--disable-versioning could be split to separate feature.


_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches