[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Patches] Any remaining uses of option groups?
- To: Abdoulaye Walsimou Gaye <awg@xxxxxxxxxxxxxx>
- Subject: Re: [Patches] Any remaining uses of option groups?
- From: OndÅej BÃlka <neleai@xxxxxxxxx>
- Date: Wed, 19 Jun 2013 08:07:25 +0200
On Tue, Jun 18, 2013 at 10:23:14PM +0200, Abdoulaye Walsimou Gaye wrote:
> 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
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.
> 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