On Fri, Mar 25, 2005 at 01:23:01PM +0000, Gerrit Pape wrote: > On Fri, Mar 25, 2005 at 04:59:04AM -0800, Steve Langasek wrote: > > On Fri, Mar 25, 2005 at 12:55:59PM +0000, Gerrit Pape wrote: > > > The workaround for sparc wouldn't be necessary if the diet wrapper is > > > called with the -Os option (this adds -mcpu=supersparc), a good idea > > > anyway for all architectures.
> > It most certainly is *not* a good idea; it's contraindicated by policy to > > build binaries with -Os instead of -O2, and the idea of calling -Os to set > > -mcpu=supersparc leaves me very much afraid of what other random options > > diet would set. > It's that diet libc is meant to produce statically linked binaries > optimized for size; that's what it's designed for. Here're the options > it uses on Debian, I'm not aware of any problems they cause. As it's explained to me, util-vserver's use of dietlibc has nothing to do with a need for small binaries; it's because the package is used in a chroot-intensive environment and should not depend on glibc's NSS. As a result, I don't see any reason to use -Os when building util-vserver. I think the idea of having -Os do *anything* besides setting "-Os" is shaky, FWIW. Other than overriding the CPU selection on sparc, the other problem I see with the chosen options is that you use -fomit-frame-pointer everywhere, which discards valuable debugging information for no discernible gain... -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
