add -fPIC option for shared libbusybox.so

[Rob Landley]

On Wednesday 03 May 2006 4:36 pm, Bernhard Fischer wrote:
> >1) There is one "shared library" switch.  We either build libbb.a or
> > libbb.so.
>
> I agree with this one (module the naming, of course; we're not talking
> about libbb/*.c only but {*/,./}lib*)

So if there's no static library to link busybox against, how do we build a 
busybox that uses those functions but doesn't link against them in any way?

> >2) If we build the shared library, we link the busybox we build against
> > it. 3) If you want a shared library with everything in it, you build a
> > defconfig (or even allyesconfig) busybox, and grab that shared library.
>
> I tend to dislike this since it isn't flexible. See below.
>
> >If you want to build a shared library, and also build a busybox that
> > doesn't use the shared library, you can run the build twice.
>
> That's awkward IMHO. What other opensource projects do pursue the
> approach of configuring, make, re-configuring, re-make? That sounds
> quite broken to me.

Well, start by showing me other projects that have a similar set of 
configuration options.

> >> I'm convinced that it is pretty straight forward to completely rewrite
> >> busybox' buildsystem to be small and easy to understand and to work with
> >> GNU make-3.x. I'm currently not willing to invest the time needed to do
> >> this and support it, though (i already spent too much "invain" time for
> >> something that didn't work out to be generally supportable, so i will
> >> not revisit this topic during the next couple of months, fwiw).
> >
> >I don't like the idea of the build system doing the same thing multiple
> > times in slightly different ways to produce multiple different kind of
> > results in
>
> Providing means to the user so she can achive what she wants in one
> configure-make-cycle is the plastic solution. ;)

Providing an extensively complicated makefile that keeps track of several 
different independent build targets in parallel and has options to build the 
same thing more than one way at the same time while attempting to resolve 
conflicts between them is not the cheap plastic solution, no.

> It just works.

But it didn't.  It had *.o and *.om built from the same file, and an 
incredible amount of unnecessary complexity that wasn't portable and wasn't 
easily understandable.  More to the point, it wasn't maintainable.

> Whether we build an .o with or without -fPIC should certainly not put a
> burden unto the user. It's purely internal cosmetic stuff, nothing more
> and nothing fancy.

We should build each .c file once.  We shouldn't build anything we're not 
going to use.  libbusybox.so is _not_ an independent install target.  It's 
either something busybox produces because busybox is using it, or it doesn't 
exist.

> >parallel.  I just don't want to go there.  You aim, you pull the trigger,
> >then you aim again.  I like that approach.
>
> This approach is cumbersome, involving for those who are asked to
> support the "Q: It doesn't work for me!!!!! A: reconfigure, rebuild"
> stanza *interactively* and it's silly to do since it's easy to do it
> automatically without giving the user opportunity to screw it up in any
> way.

If having the option to build a shared library is too complicated, then we 
don't have to do it at all.  Busybox has gotten along for many years without 
a shared library.  There's no rush to do it wrong.

> No aiming, pull trigger, reaim, trigger. That's what automatism is for ;)

The build system is not the place for extensive automation.  It's too 
complicated as it is.

> Speaking of that.. How about your script to generate the svn-patches?
> Did you already fix that so it is invoked when someone does check
> something in?

Nope.  A) that's not a "fix", that's a new feature requiring a fairly 
extensive rewrite of the script.  (Or probably just a new script.)  B) Erik 
administers the svn on there, not me.

I emailed a copy of the script to Erik in case he wanted to do anything with 
it.  It's a shared server with several different projects in the same svn 
(busybox, uclibc, uclibc++, udhcp, the vestigial tinylogin, etc), and trying 
to change the behavior for just _one_ of those projects sounds tricky.

I'd be more likely to have it run from a cron job, since that could use the 
existing script and isn't likely to break uClibc.  I just haven't bothered.  
(Didn't know anybody else cared about the patches directory...)

Rob
-- 
Never bet against the cheap plastic solution.