[patch] build shared library

[Rob Landley]

On Wednesday 07 September 2005 14:11, Bernhard Fischer wrote:
> On Tue, Sep 06, 2005 at 11:56:55PM -0500, Rob Landley wrote:
> >On Tuesday 06 September 2005 07:48, Allan Clark wrote:
> >> It sould be simple to convert a list of files to a makefile using some
> >> kind of awk, piping that to "make -f -", but it would save little over
> >> using a makefile that called out specific targets.
> >
> >I've fiddled with building lots of stuff.  Maybe half the applets can be
> > built using just one file (whatever the *.c file is for that applet
> > name).
> >
> >The next largest set of low hanging fruit is applets that need to link
> > with things like "libcoreutils", which really should be consolidated with
> > libbb.
>
> Something like the attached?

Coolness!

<cluelessness>

> -if [ "$prefix" = "" ]; then
> +# Some versions of [ can't deal with empty strings for the '=' operation
> +if [ "x$prefix" = "x" ]; then
>     echo "No installation directory, aborting."
>     exit 1;
> fi

Is 'if [ -z "$prefix" ]' not portable or something?

Figuring out where to install ($libdir) is ugly.  I'm not saying this is your 
fault, I'm just stating a fact... :)

Where does -lcrypt come in?  (You're sticking it on LIBRARIES...)

> libbusybox-soname:=libbusybox.so.1.0.0

Possibly something like:

libbusybox-soname:=libbusybox.so.$(VERSION)

(defined in Rules.mak, and I just upgraded it to say 1.1.0-pre1).

While you're touching clean: how do we fix it so the "make clean" from 
scripts/config actually gets called, and deletes "conf" and "mconf" out of 
there?  I recently modified confdata.c (to force non-visible submenus to get 
written out so the ENABLE_ stuff has 0 for all those symbols rather than 
undefined) and it didn't rebuild "conf" unless you went in by hand and hit it 
with a large hammer, and even "make clean" didn't help here...

>  ifeq ($(strip $(CONFIG_STATIC)),y)
>      LDFLAGS += --static
> +else
> +    LIBRARIES += -ldl
> +endif

I'm confused by this: what does this change about the build if neither 
CONFIG_STATIC nor CONFIG_BUILD_LIBBUSYBOX are set?  It looks like it's 
changing something, and I don't understand what...

(This is the only thing preventing me from applying it right now: I don't want 
to change the build for existing users who aren't playing with this 
experimental new feature...)

</cluelesssness> (warning: these things nest)

> Note that you will need to 'make libbusybox.so' since $(libraries-m) is
> currently empty to not harm innocent third parties which just invoke
> make.
> There y number of duplicate symbols in libunarchive exposed by this
> which ought to be fixed regardless of that patch in this varian to go in
> or not.

Yup.  Usually variants of "get_header_ar.o" is in LIBUNARCHIVE-$(CONFIG_AR) 
but also in DPKG_FILES (included in two DPKG LIBUNARCHIVEs...)

Not sure how to untangle this.  How does the linux kernel deal with this?  
(Can we wash it through sort -u maybe?)

> I urge anyone interrested in trying it out and fixing libunarchive.

Well, one thing I have in mind is going through this and shooting a lot of 
libunarchive in the head, ala:

http://www.busybox.net/lists/busybox/2005-August/015678.html

> >P.S.  part of the reason I've dredged standalone back up and put more work
> >into it recently is it lets us close bug 18. :)
>
> For this to work, we need to check at least if the preprocessor is
> satisfied, i.e. provide fallbacks for {,UN}RESERVE_CONFIG_BUFFER. If
> it's acceptable to link against abovementioned libbusybox.so, then we
> need to provide the definitions for the functions exposed by libbusybox
> (e.g. xmalloc to name just one).

What I was doing before was linking against libbb/libbb.a, which worked just 
fine.  Never messed with CONFIG_BUFFER.  That's just macros.

Rob