First Step in allowing Static / shared library choice
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 renamed from Config.in.orig +5 -0
@@ -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
Signature · 2 lines
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.
Quoted 11 lines · 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 variablesBR2_STATIC_LIBSandBR2_SHARED_LIBSare 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,
Quoted 21 lines · Bernhard Fischer-6 wrote:
Quoted 11 lines · 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 variablesBR2_STATIC_LIBSandBR2_SHARED_LIBSare 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?
Quoted 7 lines
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
Signature · 2 lines
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.
Quoted 25 lines · Daniel Laird
Quoted 21 lines · Bernhard Fischer-6 wrote:
Quoted 11 lines · 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 variablesBR2_STATIC_LIBSandBR2_SHARED_LIBSare 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?
Quoted 8 lines
Quoted 1 line
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 maybeBR2_TOOLCHAIN_STATIC_LIBSetc 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?
Quoted 35 lines · Bernhard Fischer
Quoted 25 lines · Daniel Laird
Quoted 21 lines · Bernhard Fischer-6 wrote:
Quoted 11 lines · 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 variablesBR2_STATIC_LIBSandBR2_SHARED_LIBSare 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?Quoted 8 lines
Quoted 1 line
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 maybeBR2_TOOLCHAIN_STATIC_LIBSetc as i think these options should be different to the package options
what do you think
Quoted 5 lines
TARGET_CONFIGURE_OPTSget _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.
Quoted 13 lines · Bernhard Fischer-6 wrote:
Quoted 7 lines
TARGET_CONFIGURE_OPTSget _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 moveDISABLE_NLSandDISABLE_LARGEFILEinto theseTARGET_CONFIGURE_FLAGS, so this isn't too bad.
Quoted 6 lines
_______________________________________________
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
Signature · 2 lines
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.