[yocto] do_install() is not getting called
Hi All,
I am creating a new recipe in bsp layer. So I created a bb file inside the
recipe.
Then from the build directory, I am able to successfully compile the source
files and was able to create the library ( bitbake -c compile -f package_name
). This is a makefile based package and I don't have an install target in my
Makefile. So I am writing a do_install in my bb file and I am doing install
there. I can see that do_compile task is getting called. But do_install ( which
was overridden in my bb file ) task is not called and the images and libraries
are not installed in the sysroots directory.
Bitbake Snippet :
SRC_URI = file://src/
PV = 1.0
S = ${WORKDIR}/src/
EXTRA_OEMAKE = CFLAGS=--sysroot=${PKG_CONFIG_SYSROOT_DIR} 'LDFLAGS=-lpthread
-lrt ${LDFLAGS}'
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir}
INCLUDEDIR=${includedir}
install -d ${D}${includedir}/
for f in ${S}/*.h; do install -m 0644 $f ${D}${includedir}/ done
}
PARALLEL_MAKE =
#BBCLASSEXTEND = native
Could you please suggest why do_install is not getting called for this Makefile
based system ? --
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_install() is not getting called
Am 08.11.2014 13:10 schrieb hari kumar harikumar...@yahoo.co.in:
Hi All,
I am creating a new recipe in bsp layer. So I created a bb file inside
the recipe.
Then from the build directory, I am able to successfully compile the
source files and was able to create the library ( bitbake -c compile -f
package_name ). This is a makefile based package and I don't have an
install target in my Makefile. So I am writing a do_install in my bb file
and I am doing install there. I can see that do_compile task is getting
called. But do_install ( which was overridden in my bb file ) task is not
called and the images and libraries are not installed in the sysroots
directory.
By running bitbake -f -c compile the do_install is not called. Either you
call bitbacke package_name or to force install butbake -c install.
Sometime a clean or cleanall before a compile also helps. This is needed if
you already had a successfull run.
Regards
Christian
Bitbake Snippet :
SRC_URI = file://src/
PV = 1.0
S = ${WORKDIR}/src/
EXTRA_OEMAKE = CFLAGS=--sysroot=${PKG_CONFIG_SYSROOT_DIR}
'LDFLAGS=-lpthread -lrt ${LDFLAGS}'
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir}
INCLUDEDIR=${includedir}
install -d ${D}${includedir}/
for f in ${S}/*.h; do
install -m 0644 $f ${D}${includedir}/
done
}
PARALLEL_MAKE =
#BBCLASSEXTEND = native
Could you please suggest why do_install is not getting called for this
Makefile based system ?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Perl: fix PERL5LIB settings
Am 07.11.2014 um 12:55 schrieb Burton, Ross ross.bur...@intel.com: Hi Wolfgang, On 5 November 2014 19:29, Wolfgang Denk w...@denx.de wrote: meta/recipes-devtools/perl/perl-native_5.14.3.bb | 4 ++-- meta/recipes-devtools/perl/perl_5.14.3.bb| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Perl was upgraded to 5.20.0 in July, can you rebase and verify that this is still required? I can finally confirm that it fixes the issues in daisy (bitbaking Dancer2 using https://github.com/rehsack/meta-cpan/tree/master/recipes-www/dancer2-perl). You can try whether Dancer2 bitbakes for dizzy and/or master to verify - for me it's impossible to create a dizzy build - to many daisy adoptions and release pressure for next weeks. If you know someone having dizzy - bitbake Dancer2, Unix::Statgrab or alike to prove ... Cheers -- Jens Rehsack rehs...@gmail.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build optimization question
So I am using core-image-minimal and trying to shrink things as much as possible for boot speed. I wrap the bitbake command in some other commands to basically extract the image and then attach it to a kernel as a ramdisk. So the size of the image is critical to boot speed. In some of my custom packages I have used -Os in the gcc command line. Is there a way to set this globally for all the packages built into the image? Any other hints or tips to reduce the size of the build? Or potential changes to u-boot to make it load faster? This is running on a beaglebone black. Thanks, Dean -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build optimization question
On Nov 8, 2014 9:02 AM, Dean d...@ripperd.com wrote: So I am using core-image-minimal and trying to shrink things as much as possible for boot speed. I wrap the bitbake command in some other commands to basically extract the image and then attach it to a kernel as a ramdisk. So the size of the image is critical to boot speed. In some of my custom packages I have used -Os in the gcc command line. Is there a way to set this globally for all the packages built into the image? Any other hints or tips to reduce the size of the build? Or potential changes to u-boot to make it load faster? This is running on a beaglebone black. Thanks, Dean -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ... I've been noticing over the last few releases that core - image - minimal isn't so minimal anymore. Its been picking up weight as it ages (like me). I'm planning to just start excluding some of the packages in it ... I don't need sound, wireless, Bluetooth etc. Regards, Brian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build optimization question
On Nov 8, 2014 9:23 AM, Brian Hutchinson b.hutch...@gmail.com wrote: On Nov 8, 2014 9:02 AM, Dean d...@ripperd.com wrote: So I am using core-image-minimal and trying to shrink things as much as possible for boot speed. I wrap the bitbake command in some other commands to basically extract the image and then attach it to a kernel as a ramdisk. So the size of the image is critical to boot speed. In some of my custom packages I have used -Os in the gcc command line. Is there a way to set this globally for all the packages built into the image? Any other hints or tips to reduce the size of the build? Or potential changes to u-boot to make it load faster? This is running on a beaglebone black. Thanks, Dean -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ... I've been noticing over the last few releases that core - image - minimal isn't so minimal anymore. Its been picking up weight as it ages (like me). I'm planning to just start excluding some of the packages in it ... I don't need sound, wireless, Bluetooth etc. Regards, Brian ... going from memory about my last dizzy build, /use/share was 35M. I've been using the rootfs tar to build my image and exclude some of this stuff but I need to look into ways to tame this kind of thing with recipes etc. Regards, Brian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build optimization question
On 8 November 2014 14:23, Brian Hutchinson b.hutch...@gmail.com wrote: I'm planning to just start excluding some of the packages in it ... I don't need sound, wireless, Bluetooth etc. If you don't need sound, wifi, and bluetooth then remove the relevant flags from DISTRO_FEATURES and they'll never be built. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] [meta-mingw] *-mingw32.conf: Add whitelist of WINDRES and RC to hash
WINDRES and RC values are exported when building for a mingw32 target. These
values, due to being exported, end up in the signature hash for everything in
the system. By adding these to the whitelist we prevent contamination and
allow the system to properly reuse existing -native and other sstate-cache.
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
conf/machine-sdk/i686-mingw32.conf | 2 ++
conf/machine-sdk/x86_64-mingw32.conf | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/conf/machine-sdk/i686-mingw32.conf
b/conf/machine-sdk/i686-mingw32.conf
index eec3ced..0bdedaa 100644
--- a/conf/machine-sdk/i686-mingw32.conf
+++ b/conf/machine-sdk/i686-mingw32.conf
@@ -27,3 +27,5 @@ MACHINEOVERRIDES .= :sdkmingw32
export WINDRES = ${HOST_PREFIX}windres --include-dir=${STAGING_INCDIR}
export RC = ${WINDRES}
+
+BB_HASHBASE_WHITELIST_append = WINDRES RC
diff --git a/conf/machine-sdk/x86_64-mingw32.conf
b/conf/machine-sdk/x86_64-mingw32.conf
index be9a8c4..5e80dfa 100644
--- a/conf/machine-sdk/x86_64-mingw32.conf
+++ b/conf/machine-sdk/x86_64-mingw32.conf
@@ -26,4 +26,6 @@ SDKPKGSUFFIX = nativesdk-mingw32
MACHINEOVERRIDES .= :sdkmingw32
export WINDRES = ${HOST_PREFIX}windres --include-dir=${STAGING_INCDIR}
-export RC = ${WINDRES}
\ No newline at end of file
+export RC = ${WINDRES}
+
+BB_HASHBASE_WHITELIST_append = WINDRES RC
--
2.0.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] [meta-mingw] Add whitelist of WINDRES and RC to hash
Add the two specific exported values to the hash, otherwise task hashes change and things rebuild unnecessarily. (perl-native may also fail to rebuild.) Mark Hatle (1): *-mingw32.conf: Add whitelist of WINDRES and RC to hash conf/machine-sdk/i686-mingw32.conf | 2 ++ conf/machine-sdk/x86_64-mingw32.conf | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-) -- 2.0.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build optimization question
Take a look at poky-tiny distro: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/poky-tiny.conf As you are using BBB you can optimize u-boot code and remove some board detection steps. I noticed that MLO generated by u-boot 2014.07 mainline is too much faster than the old ones. Regards, -- *dS Diego Sueiro sent from mobile. Em 08/11/2014 12:54, Burton, Ross ross.bur...@intel.com escreveu: On 8 November 2014 14:23, Brian Hutchinson b.hutch...@gmail.com wrote: I'm planning to just start excluding some of the packages in it ... I don't need sound, wireless, Bluetooth etc. If you don't need sound, wifi, and bluetooth then remove the relevant flags from DISTRO_FEATURES and they'll never be built. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build optimization question
Diego, I agree with Ross here in from my experience with embedded systems the three best ways to strip your root file system are by removing unneeded boot loader coe, removing unneeded kernel components and that of striping your middle ware to smaller versions like Busybox and other similiar packages like elibc. Also running strip after your debugging is done for the target can strip your code even further, there are cases of stripping large programs like the kernel down from 20 megabytes to 2. Lastly, linking Busybox statically is great if you don't need a reason to link it against a C library implementation as static versions of Busybox can easily be less then 10 megabytes from my reading and experience. Regards Nick On 14-11-08 01:03 PM, Diego Sueiro wrote: Take a look at poky-tiny distro: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/poky-tiny.conf As you are using BBB you can optimize u-boot code and remove some board detection steps. I noticed that MLO generated by u-boot 2014.07 mainline is too much faster than the old ones. Regards, -- *dS Diego Sueiro sent from mobile. Em 08/11/2014 12:54, Burton, Ross ross.bur...@intel.com escreveu: On 8 November 2014 14:23, Brian Hutchinson b.hutch...@gmail.com wrote: I'm planning to just start excluding some of the packages in it ... I don't need sound, wireless, Bluetooth etc. If you don't need sound, wifi, and bluetooth then remove the relevant flags from DISTRO_FEATURES and they'll never be built. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
