buildroot: Makefile: Allow target board makefile fill in default target_skeleton path.
PATCH 1/1 buildroot: Makefile: Allow target board makefile fill in default target_skeleton path.
From: Sonic Zhang <[email protected]>
If the target skeleton path is empty in config, don't change variable TARGET_SKELETON in buildroot Makefile. Allow the target board makefile fill in a default path.
--- Makefile | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
Makefile +2 -0
@@ -399,8 +399,10 @@ $(STAGING_DIR): @ln -snf $(STAGING_DIR) $(BASE_DIR)/staging ifeq ($(BR2_ROOTFS_SKELETON_CUSTOM),y) +ifneq ($(BR2_ROOTFS_SKELETON_CUSTOM_PATH),"") TARGET_SKELETON=$(BR2_ROOTFS_SKELETON_CUSTOM_PATH) endif +endif $(BUILD_DIR)/.root: mkdir -p $(TARGET_DIR)
Signature · 1 line
1.7.0.4
PATCH 1/1 buildroot: Makefile: Allow target board makefile fill in default target_skeleton path.
Le Wed, 8 Aug 2012 14:57:19 +0800,
Sonic Zhang <[email protected]> a ?crit :
Quoted 3 lines
If the target skeleton path is empty in config, don't change variable
TARGET_SKELETONin buildrootMakefile. Allow the target board makefile fill in a default path.
The concept of "target board makefile" does not exist. It used to exist in earlier versions of Buildroot, but it no longer exists in newer versions. Thus, I have the feeling that rather than fixing this, it is the way your boards are supported that should be modified according to the newer Buildroot good practices.
The practices in terms of board support are:
* One defconfig file per board in configs/, generally named <vendor>_<boardname>_defconfig. Those files must be generated with 'make savedefconfig'
* Utility files (kernel patches, kernel configuration files and other stuff), should be stored in board/<vendor>/<boardname>/. Kernel configuration files must be generated with 'make savedefconfig' as well.
* Using a different skeleton from the default one provided by Buildroot is really *not* recommended. Instead, if anything needs to be tweaked in the filesystem, use the post-build script for that effect. This allows to avoid duplicating the skeleton for each and every board, causing a maintenance nightmare when we want to change something in this skeleton.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 buildroot: Makefile: Allow target board makefile fill in default target_skeleton path.
Hi Thomas,
Quoted 7 lines · Thomas Petazzoni
Le Wed, 8 Aug 2012 14:57:19 +0800,
Sonic Zhang <[email protected]> a ?crit :Quoted 3 lines
If the target skeleton path is empty in config, don't change variable
TARGET_SKELETONin buildrootMakefile. Allow the target board makefile fill in a default path.
Quoted 5 lines
The concept of "target board makefile" does not exist. It used to exist in earlier versions of Buildroot, but it no longer exists in newer versions. Thus, I have the feeling that rather than fixing this, it is the way your boards are supported that should be modified according to the newer Buildroot good practices.
If "target board makefile" doesn't exit, where should we add arch specific makefile targets and compile/link flags? Where should arch specific Config options be put? Take blackfin specific makefile as an example bellow.
Makefile.in
----------------TARGET_CFLAGS += -D__NOMMU__ -D__uClinux__ -D_GNU_SOURCE ifeq ($(BR2_ABI_FLAT),y)TARGET_LDFLAGS += -Wl,-elf2flt
endif
ifeq ($(BR2_BFIN_SHARED_FLAT), y)TARGET_LDFLAGS += -mid-shared-library -mshared-library-id=0 TARGET_CFLAGS += -mid-shared-library -mshared-library-id=0 TARGET_CXXFLAGS += -mid-shared-library -mshared-library-id=0 endif
CROSS_COMPILE_SHARED_ELF ?= bfin-linux-uclibc-
romfs.shared.libs.elf:
set -e; \
t=`$(CROSS_COMPILE_SHARED_ELF)gcc $(CPUFLAGS)
-print-file-name=libc.a`; \
t=`dirname $$t`/../..; \
for i in $$t/lib/*so*; do \
i=`readlink -f "$$i"`; \
soname=`$(CROSS_COMPILE_SHARED_ELF)readelf -d "$$i" |
sed -n '/(SONAME)/s:.*[[]\(.*\)[]].*:\1:p'`; \
$(INSTALL) -D $$i $(TARGET_DIR)/lib/$$soname; \
doneCROSS_COMPILE_SHARED_FLAT ?= bfin-uclinux-
romfs.shared.libs.flat:
set -e; \
t=`$(CROSS_COMPILE_SHARED_FLAT)gcc $(CPUFLAGS)
-mid-shared-library -print-file-name=libc`; \
if [ -f $$t -a ! -h $$t ] ; then \
$(INSTALL) -D $$t $(TARGET_DIR)/lib/lib1.so; \
fiConfig.in
----------------------------------------------------
config BR2_TARGET_ANALOGDEVICES_INSTALL_ELF_SHARED
bool "Install ELF shared libraries" if !BR2_BFIN_FDPIC default y
config BR2_TARGET_ANALOGDEVICES_INSTALL_FLAT_SHARED
bool "Install FLAT shared libraries" if !BR2_BFIN_SHARED_FLAT default y
Quoted 12 lines
The practices in terms of board support are:
* One defconfig file per board in configs/, generally named <vendor>_<boardname>_defconfig. Those files must be generated with 'make savedefconfig'
* Utility files (kernel patches, kernel configuration files and other stuff), should be stored in board/<vendor>/<boardname>/. Kernel configuration files must be generated with 'make savedefconfig' as well.
Quoted 7 lines
* Using a different skeleton from the default one provided by Buildroot is really *not* recommended. Instead, if anything needs to be tweaked in the filesystem, use the post-build script for that effect. This allows to avoid duplicating the skeleton for each and every board, causing a maintenance nightmare when we want to change something in this skeleton.
Blackfin Linux distribution has a different file system layout from current default one in buildroot. And we have no plan to deviate from current one used for years. Anyway without this patch, we can still set a custom skeleton for blackfin.
Regards,
Sonic
PATCH 1/1 buildroot: Makefile: Allow target board makefile fill in default target_skeleton path.
Hello,
Le Thu, 9 Aug 2012 18:26:54 +0800,
Sonic Zhang <[email protected]> a ?crit :
Quoted 4 lines
If "target board makefile" doesn't exit, where should we add arch specific makefile targets and compile/link flags? Where should arch specific Config options be put? Take blackfin specific makefile as an example bellow.
There is no general rule for this, it depends on each thing you want to add. For things that must be added globally, package/Makefile.in is usually the current place (though this file would probably need some cleanup, but this is a different topic).
Quoted 3 lines
Makefile.in
----------------TARGET_CFLAGS+= -D__NOMMU__ -D__uClinux__ -D_GNU_SOURCE
I don't think the -D_GNU_SOURCE should be passed globally to all packages. Each package should define it if it is needed to build this package.
Also, before globally defining __NOMMU__ and __uClinux__, I'd like to understand why they are needed. I think __NOMMU__ is generally used to test whether fork() or vfork() should be used, but this should probably be tested using autoconf tests when possible.
That said, if such flags are indeed necessary, package/Makefile.in is a good place for that.
Quoted 8 lines
ifeq ($(BR2_ABI_FLAT),y)
TARGET_LDFLAGS+= -Wl,-elf2flt
endif
ifeq ($(BR2_BFIN_SHARED_FLAT), y)TARGET_LDFLAGS+= -mid-shared-library -mshared-library-id=0TARGET_CFLAGS+= -mid-shared-library -mshared-library-id=0TARGET_CXXFLAGS+= -mid-shared-library -mshared-library-id=0 endif
Same thing for these flags, package/Makefile.in.
Quoted 1 line
CROSS_COMPILE_SHARED_ELF?= bfin-linux-uclibc-
No, this should use the existing variables to get the cross-compiler location.
Quoted 11 lines
romfs.shared.libs.elf:
set -e; \ t=`$(CROSS_COMPILE_SHARED_ELF)gcc $(CPUFLAGS) -print-file-name=libc.a`; \ t=`dirname $$t`/../..; \ for i in $$t/lib/*so*; do \ i=`readlink -f "$$i"`; \ soname=`$(CROSS_COMPILE_SHARED_ELF)readelf -d "$$i" | sed -n '/(SONAME)/s:.*[[]\(.*\)[]].*:\1:p'`; \ $(INSTALL) -D $$i $(TARGET_DIR)/lib/$$soname; \ done
Why is this needed? How is this romfs.shared.libs.elf target being used?
Quoted 8 lines
CROSS_COMPILE_SHARED_FLAT?= bfin-uclinux-
romfs.shared.libs.flat:set -e; \ t=`$(CROSS_COMPILE_SHARED_FLAT)gcc $(CPUFLAGS) -mid-shared-library -print-file-name=libc`; \ if [ -f $$t -a ! -h $$t ] ; then \ $(INSTALL) -D $$t $(TARGET_DIR)/lib/lib1.so; \ fi
Ditto.
Quoted 9 lines
Config.in
----------------------------------------------------
configBR2_TARGET_ANALOGDEVICES_INSTALL_ELF_SHARED
bool "Install ELF shared libraries" if !BR2_BFIN_FDPIC default yconfig
BR2_TARGET_ANALOGDEVICES_INSTALL_FLAT_SHARED
bool "Install FLAT shared libraries" if !BR2_BFIN_SHARED_FLAT default y
Any reason to have these in addition to the existing selection of ABI? What are the use cases for these?
Quoted 4 lines
Blackfin Linux distribution has a different file system layout from current default one in buildroot. And we have no plan to deviate from current one used for years. Anyway without this patch, we can still set a custom skeleton for blackfin.
How does the filesystem layout differs? Depending on how it differs, having a separate skeleton may or may not be the right solution.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 buildroot: Makefile: Allow target board makefile fill in default target_skeleton path.
Quoted 15 lines · Thomas Petazzoni
Hello,
Le Thu, 9 Aug 2012 18:26:54 +0800,
Sonic Zhang <[email protected]> a ?crit :Quoted 4 lines
If "target board makefile" doesn't exit, where should we add arch specific makefile targets and compile/link flags? Where should arch specific Config options be put? Take blackfin specific makefile as an example bellow.
There is no general rule for this, it depends on each thing you want to add. For things that must be added globally, package/Makefile.in is usually the current place (though this file would probably need some cleanup, but this is a different topic).
Quoted 8 lines
Quoted 3 lines
Makefile.in
----------------TARGET_CFLAGS+= -D__NOMMU__ -D__uClinux__ -D_GNU_SOURCEI don't think the -D_GNU_SOURCE should be passed globally to all packages. Each package should define it if it is needed to build this package.
Yes, it is better to put flag GNU_SOURCE to packages.
Quoted 7 lines
Also, before globally defining
__NOMMU__and__uClinux__, I'd like to understand why they are needed. I think__NOMMU__is generally used to test whetherfork()orvfork()should be used, but this should probably be tested using autoconf tests when possible.That said, if such flags are indeed necessary, package/Makefile.in is a good place for that.
Yes, this NOMMU flag is necessary to make application built for NOMMU architecture. It is not only for fork system call, but also some memory management logic. I will move it to package/Makefile.in.
Quoted 10 lines
Quoted 9 lines
ifeq ($(BR2_ABI_FLAT),y)
TARGET_LDFLAGS+= -Wl,-elf2flt
endif
ifeq ($(BR2_BFIN_SHARED_FLAT), y)TARGET_LDFLAGS+= -mid-shared-library -mshared-library-id=0TARGET_CFLAGS+= -mid-shared-library -mshared-library-id=0TARGET_CXXFLAGS+= -mid-shared-library -mshared-library-id=0 endif
Quoted 2 lines
Same thing for these flags, package/Makefile.in.
OK.
Quoted 4 lines
Quoted 1 line
CROSS_COMPILE_SHARED_ELF?= bfin-linux-uclibc-No, this should use the existing variables to get the cross-compiler location.
CROSS_COMPILE_SHARED_ELF is not the existing variables of current cross-compiler location.
Blackfin has different cross-compiler for different ABI format. bfin-linux-uclibc- compiler here is used to install the shared elf libraries only when current cross-compiler is bfin-uclinux- and current ABI is FLAT.
I prefer to move it to target/Config.arch.in
Quoted 13 lines
Quoted 12 lines
romfs.shared.libs.elf:
set -e; \ t=`$(CROSS_COMPILE_SHARED_ELF)gcc $(CPUFLAGS) -print-file-name=libc.a`; \ t=`dirname $$t`/../..; \ for i in $$t/lib/*so*; do \ i=`readlink -f "$$i"`; \ soname=`$(CROSS_COMPILE_SHARED_ELF)readelf -d "$$i" | sed -n '/(SONAME)/s:.*[[]\(.*\)[]].*:\1:p'`; \ $(INSTALL) -D $$i $(TARGET_DIR)/lib/$$soname; \ done
Quoted 1 line
Why is this needed? How is this romfs.shared.libs.elf target being used?
The Blackfin Linux kernel supports to load both shared FLAT and shared ELF libraries by applications from the same rootfs. Customers are allowed to install ELF shared libraries into the rootfs which is built with FLAT ABI flags. Vice versa.
I prefer to move the makefile targets to target/Makefile.in and move the config options to target/Config.in.
Quoted 11 lines
Quoted 9 lines
CROSS_COMPILE_SHARED_FLAT?= bfin-uclinux-
romfs.shared.libs.flat:set -e; \ t=`$(CROSS_COMPILE_SHARED_FLAT)gcc $(CPUFLAGS) -mid-shared-library -print-file-name=libc`; \ if [ -f $$t -a ! -h $$t ] ; then \ $(INSTALL) -D $$t $(TARGET_DIR)/lib/lib1.so; \ fiDitto.
Ditto.
Quoted 7 lines
Quoted 7 lines
Config.in
----------------------------------------------------
configBR2_TARGET_ANALOGDEVICES_INSTALL_ELF_SHARED
bool "Install ELF shared libraries" if !BR2_BFIN_FDPIC default y
Quoted 7 lines
Quoted 3 lines
config
BR2_TARGET_ANALOGDEVICES_INSTALL_FLAT_SHARED
bool "Install FLAT shared libraries" if !BR2_BFIN_SHARED_FLAT default yAny reason to have these in addition to the existing selection of ABI? What are the use cases for these?
Ditto
Quoted 8 lines
Quoted 4 lines
Blackfin Linux distribution has a different file system layout from current default one in buildroot. And we have no plan to deviate from current one used for years. Anyway without this patch, we can still set a custom skeleton for blackfin.
How does the filesystem layout differs? Depending on how it differs, having a separate skeleton may or may not be the right solution.
We want to have the roofs in buildroot for BF60x consist with the rootfs in uClinux-dist for BF5xx used by customers for years. So, the default skeleton is not a smart choice for us by now.
Regards,
Sonic Zhang