svn commit: trunk/uClibc/libc/stdlib

[Peter S. Mazinger]

On Thu, 16 Feb 2006, Mike Frysinger wrote:

> On Thursday 16 February 2006 01:51, Peter S. Mazinger wrote:
> > On Wed, 15 Feb 2006, Mike Frysinger wrote:
> > > On Tuesday 14 February 2006 06:08, Peter S. Mazinger wrote:
> > > > On Mon, 13 Feb 2006, Mike Frysinger wrote:
> > > > > On Monday 13 February 2006 02:42, psm at uclibc.org wrote:
> > > > > > Author: psm
> > > > > > Date: 2006-02-12 23:42:06 -0800 (Sun, 12 Feb 2006)
> > > > > > New Revision: 13927
> > > > > >
> > > > > > Log:
> > > > > > Don't compile arc4random if option not set
> > > > > >
> > > > > > Modified:
> > > > > >    trunk/uClibc/libc/stdlib/Makefile.in
> > > > > >    trunk/uClibc/libc/stdlib/arc4random.c
> > > > >
> > > > > how is this any different from tracking the define in the file itself
> > > > > ? imo, keeping all the stuff in the one .c file helps prevents bitrot
> > > > > a lot more than spreading stuff out between the source code and the
> > > > > build files
> > > >
> > > > why should we build an empty object and add it to libc.a?
> > >
> > > as i said, it's a trade off ... and imo, preventing bitrot by keeping all
> > > the config options in one .c file rather than blending the build/source
> > > is more important
> > >
> > > btw, arc4random.o isnt the only empty .o file ... we have plenty of
> > > others from the linux subdir for example
> >
> > I would remove those as well, if possible (began doing it for the LFS
> > dependents),
> 
> i dont see how you can without some how exporting all of the __NR_* symbols 
> and LFS stuff to the build namespace
> 
> > well if you consider it a wrong approach, I will revert this 
> > and the others.
> 
> i do consider it the wrong approach ... something that would make more sense 
> in my mind would be to detect which objects are empty and filter those before 
> adding them to the final archive ... something with `readelf` perhaps ?
> -mike

what about like:
$(nm --defined-only obj | wc | awk '{print $1}')

if 0 do not include object?

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2