[busybox] some size savings

Bernhard Fischer rep.nop at aon.at
Tue Oct 11 09:50:45 UTC 2005


On Mon, Oct 10, 2005 at 07:33:31PM -0500, Rob Landley wrote:
>On Monday 10 October 2005 13:51, Bernhard Fischer wrote:

>> Also, i need to know if folks want to be able to build the individual .o
>> or not.
>
>For make standalone, perhaps.  But we can handle that later.  Sounds like 
>standalone would also benefit from this kind of thing...
>
>> E.g. for size-optimisations, should
>> rm -f libbb/bb_echo.o;make $(pwd)/libbb/bb_echo.o
>> still produce bb_echo.o or not? I could ditch the rules to build
>> individual objects if only the overall size is interresting. Note that
>> imho the overall size needed does count in the end, still i see that it
>> is useful to allow for optimizing single obj. Opinions?
>
>Vodz just got dependencies working.  How does this interact with that?

So now we have dependencies of applet.o: libbb/something.o etc.o ?
Didn't look yet, but i will keep the individual rules anyway.

>Ah, the libbb.so patch.  I think that we should probably check it in before 
>too much more goes into it (and before we get too much closer to 1.1.0-pre1).
>
>> -if [ "$prefix" = "" ]; then
>> +# Some versions of [ can't deal with empty strings for the '=' operation
>> +if [ "x$prefix" = "x" ]; then
>
>Remember -z...
ACK.
>
>> rm -f $prefix/bin/busybox || exit 1
>> mkdir -p $prefix/bin || exit 1
>>+mkdir -p $prefix/$libdir || exit 1
>> install -m 755 busybox $prefix/bin/busybox || exit 1
>
>Hmmm...  Possibly that should be conditional?  (Creating the directory when 
>libbb.so isn't selected is a user-visible change.  Admittedly the lib 
>directory will generally already be there...)

Yes, i'll make it conditional on whether busybox uses libbusybox.so or
make install-lib.
>
>>
>> +for i in libbusybox.so*
>> +do
>> + [ -f $i ] && install -m 644 $i $prefix/$libdir/
>> +done
>
>And when libbusybox.so* doesn't exist, this does what?

Then it does nothing. Note the "[ -f $i ]".
We can wrap this and the mkdir ..$libdir into a check if libs are to be
installed or not.
> 
>Now, this bit:
>
>-# Copyright (C) 1999-2004 by Erik Andersen <andersen at codepoet.org>
>-#
>-# This program is free software; you can redistribute it and/or modify
>-# it under the terms of the GNU General Public License as published by
>-# the Free Software Foundation; either version 2 of the License, or
>-# (at your option) any later version.
>-#
>-# This program is distributed in the hope that it will be useful,
>-# but WITHOUT ANY WARRANTY; without even the implied warranty of
>-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>-# General Public License for more details.
>+# Copyright (C) 1999-2005 by Erik Andersen <andersen at codepoet.org>
> #
>-# You should have received a copy of the GNU General Public License
>-# along with this program; if not, write to the Free Software
>-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>+# Licensed under the GPL v2, see the file LICENSE in this tarball.
> #
>
>Subtle legal point: the "or (at your option) any later version" just got 
>dropped, and as far as I can tell the _only_ thing allowing code to be used 
>under GPL v3 is the "at your option" clause in the license grant boilerplate.  
>(If you think I'm wrong, point to the license text please.)
Hm. That's dangerous as i just copy'n pasted it from somewhere else in
the tree.
>
>Abbreviating the boilerplate, yea.  Changing the license terms while doing so, 
>boo.

That was not intentional.. I'll have to see what other files look like
this erroneous one.
>
>Now if we just want to put the "at your option" clause into LICENSE, fine.  
>Some of our files currently say gpl v2 and some say gpl v2 or later, although 
>technically since it's in the permission grant test this has to count as dual 
>licensing rather than incompatible licenses...
>
>Yeah, I pay attention to this sort of thing. :)

Which is a good thing, as can be seen. Please continue doing so, I'll
take more care about it in the future.
>
>Okay, into libunarchive's makefile:
>
>I'm not following this enough to see whether or not the conditionals are being 
>honored.  When we want to build busybox statically linked against libbb.a, is 
>everything working ok?  I don't mind building libbusybox.so unconditionally 
>as long as A) the busybox executable produced is linked the way we want it to 
>be, B) we only install what's actually requested.
>
>The makefile.in snippets:
>
>Query: *.c is wrong why?  (What is makedep working based off of?)

It's ok, but i will have to filter out the .c which are covered by
MSRC*. I'll do that.
>
>+#above line left blank intentionally
> 
>Yank the trailing \ already.  Any cleverness that needs a comment to 
>understand also needs some real benefit to justify its existence.
>
>+# XXX: No idea how i can extract a valid soversion out of e.g.
>+# VERSION:=1.1.0-pre1
>
>Either use the whole thing or sed 's/-.*//', or possibly:
>sed -r 's/[-a-zA-Z]{1,}/\./'

Yes, with $(shell echo | sed ) it's easy, but how would i do this with
make builtins?

>
>+libbusybox.so: $(libbusybox-obj)
>+ $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(LDFLAGS) -shared \
>+ $(CFLAGS_PIC) -msingle-pic-base \
>+ -Wl,-soname=$(libbusybox-soname) \
>+ -Wl,--enable-new-dtags -Wl,--reduce-memory-overheads \
>+ -Wl,-z,combreloc -Wl,-shared -Wl,--as-needed \
>+ -Wl,--warn-shared-textrel -Wl,--no-undefined-version \
>+ -o $(@) \
>+ -Wl,--whole-archive -Wl,--start-group $(^) \
>+ -Wl,--end-group -Wl,--no-whole-archive
>+ @rm -f $(libbusybox-soname)
>+ ln -s $(@) $(libbusybox-soname)
>+ strip --remove-section=.note --remove-section=.comment 
>--remove-section=.version --strip-debug --strip-unneeded $@
>
>Possibly this belongs in rules.mak or some such?  Getting into fairly deep 
>linker magic here...

As we would only need it in the toplevel Makefile and only build a .so
once, it would suffice to have it in the Makefile. We can put it into
Rules.mak as well, if that's the preferred place.

>
>Most I feel "check it in and we'll clean it up once it's in" rather than 
>keeping a 30k patch out of the tree, but I have very weak make-fu and would 
>feel much better if somebody who know what they were doing gave it this sniff 
>test...

I second the testing bits..



More information about the busybox mailing list