add -fPIC option for shared libbusybox.so

[Bernhard Fischer]

On Wed, May 03, 2006 at 04:14:31PM -0400, Rob Landley wrote:
>On Tuesday 02 May 2006 11:38 am, Bernhard Fischer wrote:
>> To recap:
>>
>> 1) -fPIC is needed for _any_ object which will be used as a .so.
>
>You know, I'm quite happy with the following rules regarding libbusybox.so:
>
>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*)

>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.
>
>> 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. ;)
It just works.

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.

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

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

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?


>
cheers,
>> Bernhard
>
>Rob
>-- 
>Never bet against the cheap plastic solution.
>