[Buildroot] First Step in allowing Static / shared library choice

[Buildroot] First Step in allowing Static / shared library choice

[Daniel Laird]

Following on from my question of 'how do we deal with shared and static
builds"
I enclose the following patch.
This is for the top level Config.in
It will appear under Build options
this means that the variables BR2_STATIC_LIBS and BR2_SHARED_LIBS are
available.

Once this patch is in we can start to modify packages to use this
information. (no packages modified yet)

I hope this can get into the mainline without to much difficulty

Cheers
Dan

--- Config.in.orig	2007-02-08 15:08:18.000000000 +0000
+++ Config.in	2007-02-08 15:11:24.000000000 +0000
@@ -361,6 +361,20 @@
 
 	  WARNING: This is highly experimental at the moment.
 
+config BR2_STATIC_LIBS
+	bool "Build static libs for target"
+	default n
+	help
+	    This option when selected will try and build packages with static
libraries.
+	    This will increase code size and is not recommended for embedded
systems.
+
+config BR2_SHARED_LIBS
+	bool "Build shared libs for target"
+	default y
+	help
+	    This option when selected will try and build packages as shared
libraries.
+	    This will increase loading time but minimise size.
+
 
 endmenu
-- 
View this message in context: http://www.nabble.com/First-Step-in-allowing-Static---shared-library-choice-tf3193891.html#a8867285
Sent from the BuildRoot mailing list archive at Nabble.com.

[Buildroot] First Step in allowing Static / shared library choice

[Bernhard Fischer]

On Thu, Feb 08, 2007 at 07:18:08AM -0800, Daniel Laird wrote:
>
>Following on from my question of 'how do we deal with shared and static
>builds"
>I enclose the following patch.
>This is for the top level Config.in
>It will appear under Build options
>this means that the variables BR2_STATIC_LIBS and BR2_SHARED_LIBS are
>available.
>
>Once this patch is in we can start to modify packages to use this
>information. (no packages modified yet)

Sounds good.

Can you please also add $(BR2_ENABLE_SHARED) rsp. $(BR2_ENABLE_STATIC)
variables (and the corresponding DISABLE) that get passed to
TARGET_CONFIGURE_OPTS (spelling?) to toolchain/Makefile.in or an
appropriate place?

TIA,

[Buildroot] First Step in allowing Static / shared library choice

[Daniel Laird]

Bernhard Fischer-6 wrote:
> 
> On Thu, Feb 08, 2007 at 07:18:08AM -0800, Daniel Laird wrote:
>>
>>Following on from my question of 'how do we deal with shared and static
>>builds"
>>I enclose the following patch.
>>This is for the top level Config.in
>>It will appear under Build options
>>this means that the variables BR2_STATIC_LIBS and BR2_SHARED_LIBS are
>>available.
>>
>>Once this patch is in we can start to modify packages to use this
>>information. (no packages modified yet)
> 
> Sounds good.
> 
> Can you please also add $(BR2_ENABLE_SHARED) rsp. $(BR2_ENABLE_STATIC)
> variables (and the corresponding DISABLE) that get passed to
> TARGET_CONFIGURE_OPTS (spelling?) to toolchain/Makefile.in or an
> appropriate place?
> 
> TIA,
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
> 
> 
I agree that I could do this.  However I  decided that you might want the
toolchain to be built staticly but your packages not.
I could therefore add a separate set of options to Toolchain options 
maybe BR2_TOOLCHAIN_STATIC_LIBS etc as i think these options should be
different to the package options
what do you think
Dan
-- 
View this message in context: http://www.nabble.com/First-Step-in-allowing-Static---shared-library-choice-tf3193891.html#a8870245
Sent from the BuildRoot mailing list archive at Nabble.com.

[Buildroot] First Step in allowing Static / shared library choice

[Bernhard Fischer]

On Thu, Feb 08, 2007 at 09:39:28AM -0800, Daniel Laird wrote:
>
>
>
>Bernhard Fischer-6 wrote:
>> 
>> On Thu, Feb 08, 2007 at 07:18:08AM -0800, Daniel Laird wrote:
>>>
>>>Following on from my question of 'how do we deal with shared and static
>>>builds"
>>>I enclose the following patch.
>>>This is for the top level Config.in
>>>It will appear under Build options
>>>this means that the variables BR2_STATIC_LIBS and BR2_SHARED_LIBS are
>>>available.
>>>
>>>Once this patch is in we can start to modify packages to use this
>>>information. (no packages modified yet)
>> 
>> Sounds good.
>> 
>> Can you please also add $(BR2_ENABLE_SHARED) rsp. $(BR2_ENABLE_STATIC)
>> variables (and the corresponding DISABLE) that get passed to
>> TARGET_CONFIGURE_OPTS (spelling?) to toolchain/Makefile.in or an
>> appropriate place?
>> 
>> TIA,

>I agree that I could do this.  However I  decided that you might want the
>toolchain to be built staticly but your packages not.
>I could therefore add a separate set of options to Toolchain options 
>maybe BR2_TOOLCHAIN_STATIC_LIBS etc as i think these options should be
>different to the package options
>what do you think

TARGET_CONFIGURE_OPTS get _only_ passed to target packages, be they
you-name-it package or a native compiler. Distinguishing between a
native compiler with shared lib support and the rest of the system being
static (and likely not having ld support due to this) doesn't sound like
we want to have it for a first take, ok?

[Buildroot] First Step in allowing Static / shared library choice

[Bernhard Fischer]

On Thu, Feb 08, 2007 at 06:43:08PM +0100, Bernhard Fischer wrote:
>On Thu, Feb 08, 2007 at 09:39:28AM -0800, Daniel Laird wrote:
>>
>>
>>
>>Bernhard Fischer-6 wrote:
>>> 
>>> On Thu, Feb 08, 2007 at 07:18:08AM -0800, Daniel Laird wrote:
>>>>
>>>>Following on from my question of 'how do we deal with shared and static
>>>>builds"
>>>>I enclose the following patch.
>>>>This is for the top level Config.in
>>>>It will appear under Build options
>>>>this means that the variables BR2_STATIC_LIBS and BR2_SHARED_LIBS are
>>>>available.
>>>>
>>>>Once this patch is in we can start to modify packages to use this
>>>>information. (no packages modified yet)
>>> 
>>> Sounds good.
>>> 
>>> Can you please also add $(BR2_ENABLE_SHARED) rsp. $(BR2_ENABLE_STATIC)
>>> variables (and the corresponding DISABLE) that get passed to
>>> TARGET_CONFIGURE_OPTS (spelling?) to toolchain/Makefile.in or an
>>> appropriate place?
>>> 
>>> TIA,
>
>>I agree that I could do this.  However I  decided that you might want the
>>toolchain to be built staticly but your packages not.
>>I could therefore add a separate set of options to Toolchain options 
>>maybe BR2_TOOLCHAIN_STATIC_LIBS etc as i think these options should be
>>different to the package options
>>what do you think
>
>TARGET_CONFIGURE_OPTS get _only_ passed to target packages, be they
>you-name-it package or a native compiler. Distinguishing between a
>native compiler with shared lib support and the rest of the system being
>static (and likely not having ld support due to this) doesn't sound like
>we want to have it for a first take, ok?

Those have to be called TARGET_CONFIGURE_FLAGS, of course, and we'll have
to pass them to all ./configure invocations.. manually. hmz. At least we
can at the same time move DISABLE_NLS and DISABLE_LARGEFILE into these
TARGET_CONFIGURE_FLAGS, so this isn't too bad.

[Buildroot] First Step in allowing Static / shared library choice

[Daniel Laird]

Bernhard Fischer-6 wrote:
> 
>>
>>TARGET_CONFIGURE_OPTS get _only_ passed to target packages, be they
>>you-name-it package or a native compiler. Distinguishing between a
>>native compiler with shared lib support and the rest of the system being
>>static (and likely not having ld support due to this) doesn't sound like
>>we want to have it for a first take, ok?
> 
> Those have to be called TARGET_CONFIGURE_FLAGS, of course, and we'll have
> to pass them to all ./configure invocations.. manually. hmz. At least we
> can at the same time move DISABLE_NLS and DISABLE_LARGEFILE into these
> TARGET_CONFIGURE_FLAGS, so this isn't too bad.
> 
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
> 
> 

I do not think this is the best idea.  I would like to stick with the way we
handle DISABLE_NLS etc.  The reason is that if we pass all of these
configure options to all ./configure calls in the packages then they have to
all work. or at least not cause an error from the program configure.  Are we
certain that all packages will not error when calling ./configure
--disable-nls for example?
If you think that ./configure for all packages will not fail as long as you
use --enable-XXX --disable-XXX --without-XXX --with-XXX then maybe this will
work.
Cheers
Dan

-- 
View this message in context: http://www.nabble.com/First-Step-in-allowing-Static---shared-library-choice-tf3193891.html#a8882941
Sent from the BuildRoot mailing list archive at Nabble.com.