On Fri, Mar 25, 2005 at 05:44:40AM -0800, Steve Langasek wrote: > 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: > > > 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.
Ah ok. I now also see it's the upstream author of util-vserver who contributed most of the changes that I included in the recent upload to the dietlibc development ;-). Looks like he put quite some work into it.. > 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... Nearly all of the options is upstream's choice, and I think the porters of the different architectures measured the efficiency of the options regarding size optimization. Generally I prefer to make as less changes to upstream as possible, and these options are in place for quite some time, used with various compiler version. I well understand your point of view though. Thanks, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
