[patch] build shared library

[Bernhard Fischer]

On Thu, Sep 08, 2005 at 12:16:02AM -0500, Rob Landley wrote:
>On Wednesday 07 September 2005 14:11, Bernhard Fischer wrote:
>> On Tue, Sep 06, 2005 at 11:56:55PM -0500, Rob Landley wrote:

>> >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?

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

yeah, there ought to be a better way. I'm not convinced if it would be a
good idea to make install() aware of the obj-format and type of the file
it is asked to install. It could then decide on it's own where to put
the lib, but i think that would be a bad idea. Let's use this ugly
method for now, ok?
>
>Where does -lcrypt come in?  (You're sticking it on LIBRARIES...)

crypt is required for libbb/{correct_password,pw_encrypt}.c

You can also ditch the -lc, i think.
>
>> libbusybox-soname:=libbusybox.so.1.0.0
>
>Possibly something like:
>
>libbusybox-soname:=libbusybox.so.$(VERSION)

Yes, that's better (we have to strip the '-pre1' part, obviously).
>
>(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 

As said in another mail, scripts/conf/binaries are deleted in make
distclean.

We could as well move the line
$(MAKE) -C scripts/config clean
from distclean to clean, if you like.

>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...

drop that part, it's a leftover from building multiple libs.

>(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?)

yes. The following does the trick.

Index: archival/libunarchive/Makefile.in
===================================================================
--- archival/libunarchive/Makefile.in	(revision 11350)
+++ archival/libunarchive/Makefile.in	(working copy)
@@ -74,6 +74,7 @@
 LIBUNARCHIVE-$(CONFIG_UNCOMPRESS) += decompress_uncompress.o
 LIBUNARCHIVE-$(CONFIG_UNZIP) += $(GUNZIP_FILES)
 
+LIBUNARCHIVE-y:=$(sort $(LIBUNARCHIVE-y))
 libraries-y+=$(LIBUNARCHIVE_DIR)$(LIBUNARCHIVE_AR)
 
 $(LIBUNARCHIVE_DIR)$(LIBUNARCHIVE_AR): $(patsubst
%,$(LIBUNARCHIVE_DIR)%, $(LIBUNARCHIVE-y))