bitbake -c populate_sdk -v poky-image

bitbake -c populate_sdk -v poky-image

[Navani Srivastava]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

Hi,

I want to build meta-toolchain-qte.bb as sdk while running

"bitbake -c populate_sdk -v core-image-minimal" ..

Please suggest what changes need to be done to provide this feature?

Thanks and Regards
Navani Kamal Srivastava

[-- Attachment #2: Type: text/html, Size: 384 bytes --]

Re: bitbake -c populate_sdk -v poky-image

[Paul Eggleton]

Hi Navani,

On Monday 22 July 2013 16:33:48 Navani Srivastava wrote:
> I want to build meta-toolchain-qte.bb as sdk while running
> 
> "bitbake -c populate_sdk -v core-image-minimal" ..
> 
> Please suggest what changes need to be done to provide this feature?

At the moment you'll have to add something like the following to your image, 
after the "inherit image" or "inherit core-image" line:

TOOLCHAIN_HOST_TASK += "nativesdk-packagegroup-qte-toolchain-host"

You'll also need to append to the toolchain environment setup script. See what 
meta/recipes-qt/meta/meta-toolchain-qt.inc does and you should be able to do 
the same in your image recipe.

(I'd like to make this easier at some point in future, so that this extra stuff 
isn't needed.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: bitbake -c populate_sdk -v poky-image

[Navani Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

Thanks Paul.. It worked :)
Able to create SDK with qt inbuilt on issuing "bitbake -c populate_sdk
core-image-minimal" , but now "bitbake -v core-image-minimal" also invoke
do_populate_sdk .. Is this the expected behavior or something else?
Is there anyway to clean only sdk by using bitbake command?


>>(I'd like to make this easier at some point in future, so that this extra
stuff
isn't needed.)
It would be great and will make development easy also... Thanks for that..

Regards
Navani


On Fri, Jul 26, 2013 at 9:19 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> Hi Navani,
>
> On Monday 22 July 2013 16:33:48 Navani Srivastava wrote:
> > I want to build meta-toolchain-qte.bb as sdk while running
> >
> > "bitbake -c populate_sdk -v core-image-minimal" ..
> >
> > Please suggest what changes need to be done to provide this feature?
>
> At the moment you'll have to add something like the following to your
> image,
> after the "inherit image" or "inherit core-image" line:
>
> TOOLCHAIN_HOST_TASK += "nativesdk-packagegroup-qte-toolchain-host"
>
> You'll also need to append to the toolchain environment setup script. See
> what
> meta/recipes-qt/meta/meta-toolchain-qt.inc does and you should be able to
> do
> the same in your image recipe.
>
> (I'd like to make this easier at some point in future, so that this extra
> stuff
> isn't needed.)
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #2: Type: text/html, Size: 2185 bytes --]

Re: bitbake -c populate_sdk -v poky-image

[Paul Eggleton]

On Monday 29 July 2013 23:29:25 Navani Srivastava wrote:
> Thanks Paul.. It worked :)
> Able to create SDK with qt inbuilt on issuing "bitbake -c populate_sdk
> core-image-minimal" , but now "bitbake -v core-image-minimal" also invoke
> do_populate_sdk .. Is this the expected behavior or something else?

Er, that is certainly not expected. Would you be able to attach the current 
recipe?

> Is there anyway to clean only sdk by using bitbake command?

I'm not sure that there is, no.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: bitbake -c populate_sdk -v poky-image

[Navani Srivastava]

[-- Attachment #1.1: Type: text/plain, Size: 903 bytes --]

I have done changes in .bbclass file. Could it be the reason for such
behavior?
Please find the attached recipe and bbclass.

>>'m not sure that there is, no.
Ok, Thanks..

On Mon, Jul 29, 2013 at 11:34 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Monday 29 July 2013 23:29:25 Navani Srivastava wrote:
> > Thanks Paul.. It worked :)
> > Able to create SDK with qt inbuilt on issuing "bitbake -c populate_sdk
> > core-image-minimal" , but now "bitbake -v core-image-minimal" also invoke
> > do_populate_sdk .. Is this the expected behavior or something else?
>
> Er, that is certainly not expected. Would you be able to attach the current
> recipe?
>
> > Is there anyway to clean only sdk by using bitbake command?
>
> I'm not sure that there is, no.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

Regards
Navani

[-- Attachment #1.2: Type: text/html, Size: 1517 bytes --]

[-- Attachment #2: poky-image.bbclass --]
[-- Type: application/octet-stream, Size: 7685 bytes --]

# Common for Poky images
#
# Copyright (C) 2007 OpenedHand LTD

LIC_FILES_CHKSUM = "file://${POKYBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
                    file://${POKYBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

# IMAGE_FEATURES control content of images built with Poky.
# 
# By default we install task-poky-boot and task-base packages - this gives us
# working (console only) rootfs.
#
# Available IMAGE_FEATURES:
#
# - apps-console-core
# - x11-base            - X11 server + minimal desktop	
# - x11-sato            - OpenedHand Sato environment
# - x11-netbook         - Metacity based environment for netbooks
# - apps-x11-core       - X Terminal, file manager, file editor
# - apps-x11-games
# - apps-x11-pimlico    - OpenedHand Pimlico apps
# - tools-sdk           - SDK
# - tools-debug         - debugging tools
# - tools-profile       - profiling tools
# - tools-testapps      - tools usable to make some device tests
# - nfs-server          - NFS server (exports / over NFS to everybody)
# - dev-pkgs            - development packages
# - dbg-pkgs            - debug packages
#

POKY_BASE_INSTALL = '\
    task-poky-boot \
    task-base-extended \
    ${@base_contains("IMAGE_FEATURES", "dbg-pkgs", "task-poky-boot-dbg task-base-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", "dev-pkgs", "task-poky-boot-dev task-base-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "apps-console-core", "task-poky-apps-console", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["apps-console-core", "dbg-pkgs"], "task-poky-apps-console-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["apps-console-core", "dev-pkgs"], "task-poky-apps-console-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "x11-base", "task-poky-x11-base", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["x11-base", "dbg-pkgs"], "task-poky-x11-base-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["x11-base", "dev-pkgs"], "task-poky-x11-base-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "x11-sato", "task-poky-x11-sato", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["x11-sato", "dbg-pkgs"], "task-poky-x11-sato-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["x11-sato", "dev-pkgs"], "task-poky-x11-sato-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "x11-netbook", "task-poky-x11-netbook", "", d)} \
    ${@base_contains("IMAGE_FEATURES", ["x11-netbook", "dbg-pkgs"], "task-poky-x11-netbook-dbg", "", d)} \
    ${@base_contains("IMAGE_FEATURES", ["x11-netbook", "dev-pkgs"], "task-poky-x11-netbook-dev", "", d)} \
    ${@base_contains("IMAGE_FEATURES", "apps-x11-core", "task-poky-apps-x11-core", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["apps-x11-core", "dbg-pkgs"], "task-poky-apps-x11-core-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["apps-x11-core", "dev-pkgs"], "task-poky-apps-x11-core-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "apps-x11-games", "task-poky-apps-x11-games", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["apps-x11-games", "dbg-pkgs"], "task-poky-apps-x11-games-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["apps-x11-games", "dev-pkgs"], "task-poky-apps-x11-games-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "apps-x11-pimlico", "task-poky-apps-x11-pimlico", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["apps-x11-pimlico", "dbg-pkgs"], "task-poky-apps-x11-pimlico-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["apps-x11-pimlico", "dev-pkgs"], "task-poky-apps-x11-pimlico-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "tools-debug", "task-poky-tools-debug", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["tools-debug", "dbg-pkgs"], "task-poky-tools-debug-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["tools-debug", "dev-pkgs"], "task-poky-tools-debug-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "tools-profile", "task-poky-tools-profile", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["tools-profile", "dbg-pkgs"], "task-poky-tools-profile-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["tools-profile", "dev-pkgs"], "task-poky-tools-profile-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "tools-testapps", "task-poky-tools-testapps", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["tools-testapps", "dbg-pkgs"], "task-poky-tools-testapps-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["tools-testapps", "dev-pkgs"], "task-poky-tools-testapps-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "tools-sdk", "task-poky-sdk task-poky-standalone-sdk-target", "",d)} \    
    ${@base_contains("IMAGE_FEATURES", ["tools-sdk", "dbg-pkgs"], "task-poky-sdk-dbg", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["tools-sdk", "dev-pkgs"], "task-poky-sdk-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "nfs-server", "task-poky-nfs-server", "",d)} \
    ${@base_contains("IMAGE_FEATURES", ["nfs-server", "dbg-pkgs"], "task-poky-nfs-server-dbg", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", ["nfs-server", "dev-pkgs"], "task-poky-nfs-server-dev", "",d)} \
    \
    ${@base_contains("IMAGE_FEATURES", "package-management", "${ROOTFS_PKGMANAGE}", "${ROOTFS_PKGMANAGE_BOOTSTRAP}",d)} \
    ${@base_contains("IMAGE_FEATURES", "qt4-pkgs", "task-poky-qt-demos", "",d)} \
    ${POKY_EXTRA_INSTALL} \
    '

POKY_EXTRA_INSTALL ?= ""

IMAGE_INSTALL ?= "${POKY_BASE_INSTALL}"

X11_IMAGE_FEATURES  = "x11-base apps-x11-core package-management"
ENHANCED_IMAGE_FEATURES = "${X11_IMAGE_FEATURES} apps-x11-games apps-x11-pimlico package-management"
SATO_IMAGE_FEATURES = "${ENHANCED_IMAGE_FEATURES} x11-sato"

inherit image
require recipes-core/meta/meta-toolchain.bb

TOOLCHAIN_HOST_TASK = "task-qte-toolchain-host-nativesdk task-cross-canadian-${TRANSLATED_TARGET_ARCH}"
TOOLCHAIN_TARGET_TASK = "task-qte-toolchain-target"
TOOLCHAIN_OUTPUTNAME = "${SDK_NAME}-toolchain-qte-${DISTRO_VERSION}"

QT_DIR_NAME = "qtopia"
QT_TOOLS_PREFIX = "${SDKPATHNATIVE}${bindir_nativesdk}"

toolchain_create_sdk_env_script_append() {
    echo 'export OE_QMAKE_CFLAGS="$CFLAGS"' >> $script
    echo 'export OE_QMAKE_CXXFLAGS="$CXXFLAGS"' >> $script
    echo 'export OE_QMAKE_LDFLAGS="$LDFLAGS"' >> $script
    echo 'export OE_QMAKE_CC=${TARGET_PREFIX}gcc' >> $script
    echo 'export OE_QMAKE_CXX=${TARGET_PREFIX}g++' >> $script
    echo 'export OE_QMAKE_LINK=${TARGET_PREFIX}g++' >> $script
    echo 'export OE_QMAKE_AR=${TARGET_PREFIX}ar' >> $script
    echo 'export OE_QMAKE_LIBDIR_QT=${SDKTARGETSYSROOT}/${libdir}' >> $script
    echo 'export OE_QMAKE_INCDIR_QT=${SDKTARGETSYSROOT}/${includedir}/${QT_DIR_NAME}' >> $script
    echo 'export OE_QMAKE_MOC=${QT_TOOLS_PREFIX}/moc4' >> $script
    echo 'export OE_QMAKE_UIC=${QT_TOOLS_PREFIX}/uic4' >> $script
    echo 'export OE_QMAKE_UIC3=${QT_TOOLS_PREFIX}/uic34' >> $script
    echo 'export OE_QMAKE_RCC=${QT_TOOLS_PREFIX}/rcc4' >> $script
    echo 'export OE_QMAKE_QDBUSCPP2XML=${QT_TOOLS_PREFIX}/qdbuscpp2xml4' >> $script
    echo 'export OE_QMAKE_QDBUSXML2CPP=${QT_TOOLS_PREFIX}/qdbusxml2cpp4' >> $script
    echo 'export OE_QMAKE_QT_CONFIG=${SDKTARGETSYSROOT}/${datadir}/${QT_DIR_NAME}/mkspecs/qconfig.pri' >> $script
    echo 'export QMAKESPEC=${SDKTARGETSYSROOT}/${datadir}/${QT_DIR_NAME}/mkspecs/linux-g++' >> $script

    # make a symbolic link to mkspecs for compatibility with Nokia's SDK
    # and QTCreator
    (cd ${SDK_OUTPUT}/${QT_TOOLS_PREFIX}/..; ln -s ${SDKTARGETSYSROOT}/usr/share/qtopia/mkspecs mkspecs;)
}


# Create /etc/timestamp during image construction to give a reasonably sane default time setting
ROOTFS_POSTPROCESS_COMMAND += "rootfs_update_timestamp ; "

[-- Attachment #3: poky-image.bb --]
[-- Type: application/octet-stream, Size: 658 bytes --]

#
# Copyright (C) 2007 OpenedHand Ltd.
#
#IMAGE_INSTALL = "task-poky-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP}"

IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP}"
IMAGE_INSTALL += "util-linux update-modules kernel-modules sysfsutils watchdog initscripts tslib-conf tslib-tests tslib-calibrate iproute2 can-utils gdbserver powertop strace gcov-symlinks u-boot-fw-utils dhcp-client coreutils binutils-symlinks gdb qt4-embedded directfb lcd-apps zip procps iotop alsa-utils-aplay mtd-utils unzip"
IMAGE_LINGUAS = " "

LICENSE = "MIT"

inherit poky-image
# remove not needed ipkg informations
ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; "

Re: bitbake -c populate_sdk -v poky-image

[Paul Eggleton]

On Tuesday 30 July 2013 00:08:42 Navani Srivastava wrote:
> I have done changes in .bbclass file. Could it be the reason for such
> behavior?
> Please find the attached recipe and bbclass.

I think the problem is this:

> require recipes-core/meta/meta-toolchain.bb

You shouldn't be adding this to an image recipe, and definitely not poky-
image.bbclass.

What version of the build system are you using?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: bitbake -c populate_sdk -v poky-image

[Navani Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

>>I think the problem is this:

> require recipes-core/meta/meta-toolchain.bb
Yes, it worked.. Thanks

>>You shouldn't be adding this to an image recipe, and definitely not poky-
image.bbclass.
then? Is it possible to create .bbappend kind of file for .bbclass which
can append the information or I have to duplicate toolchain-script.bbclass
in my layer?

>>What version of the build system are you using?
I am using poky danny (8.0.2)

Regards
Navani


On Tue, Jul 30, 2013 at 1:57 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Tuesday 30 July 2013 00:08:42 Navani Srivastava wrote:
> > I have done changes in .bbclass file. Could it be the reason for such
> > behavior?
> > Please find the attached recipe and bbclass.
>
> I think the problem is this:
>
> > require recipes-core/meta/meta-toolchain.bb
>
> You shouldn't be adding this to an image recipe, and definitely not poky-
> image.bbclass.
>
> What version of the build system are you using?
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #2: Type: text/html, Size: 1764 bytes --]

Re: bitbake -c populate_sdk -v poky-image

[Paul Eggleton]

On Tuesday 30 July 2013 14:35:40 Navani Srivastava wrote:
> > I think the problem is this:
> > require recipes-core/meta/meta-toolchain.bb
> 
> Yes, it worked.. Thanks
> 
> > You shouldn't be adding this to an image recipe, and definitely not poky-
> > image.bbclass.
> then? Is it possible to create .bbappend kind of file for .bbclass which
> can append the information or I have to duplicate toolchain-script.bbclass
> in my layer?

Sure, you can add the script append and the additional TOOLCHAIN_HOST_TASK 
items in an additional bbclass in your layer and then inherit that in your 
image recipe; just don't require meta-toolchain.bb because that has other 
side-effects.

> >>What version of the build system are you using?
> 
> I am using poky danny (8.0.2)

OK, in that case why are you using poky-image.bbclass? That was replaced by 
core-image.bbclass in the edison release if I recall correctly, which was 
quite a while ago.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: bitbake -c populate_sdk -v poky-image

[Navani Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

I did whatever you suggested and it worked at first shot.. Thanks a lot :)

>>In that case why are you using poky-image.bbclass?
It's is my custom recipe name suggested for the project :) Can't do
anything..



On Tue, Jul 30, 2013 at 4:18 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Tuesday 30 July 2013 14:35:40 Navani Srivastava wrote:
> > > I think the problem is this:
> > > require recipes-core/meta/meta-toolchain.bb
> >
> > Yes, it worked.. Thanks
> >
> > > You shouldn't be adding this to an image recipe, and definitely not
> poky-
> > > image.bbclass.
> > then? Is it possible to create .bbappend kind of file for .bbclass which
> > can append the information or I have to duplicate
> toolchain-script.bbclass
> > in my layer?
>
> Sure, you can add the script append and the additional TOOLCHAIN_HOST_TASK
> items in an additional bbclass in your layer and then inherit that in your
> image recipe; just don't require meta-toolchain.bb because that has other
> side-effects.
>
> > >>What version of the build system are you using?
> >
> > I am using poky danny (8.0.2)
>
> OK, in that case why are you using poky-image.bbclass? That was replaced by
> core-image.bbclass in the edison release if I recall correctly, which was
> quite a while ago.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #2: Type: text/html, Size: 2102 bytes --]

Re: bitbake -c populate_sdk -v poky-image

[Navani Srivastava]

[-- Attachment #1.1: Type: text/plain, Size: 1700 bytes --]

Hi,

Following is my image file to generate rootfs image with SDK having Qt
support..
I am able to build SDK successfully but on building any Qt application with
generated SDK getting following error message-

/opt/poky/1.3.2/sysroots/EBboard-poky-linux-gnueabi//usr/include/qtopia/QtCore/qglobal.h:68:21:
fatal error: algorithm: No such file or directory
compilation terminated.
make[2]: *** [obj_rel/AdjustedTime.o] Error 1

Please suggest..

Thanks and Regards
Navani Kamal Srivastava




On Tue, Jul 30, 2013 at 4:18 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Tuesday 30 July 2013 14:35:40 Navani Srivastava wrote:
> > > I think the problem is this:
> > > require recipes-core/meta/meta-toolchain.bb
> >
> > Yes, it worked.. Thanks
> >
> > > You shouldn't be adding this to an image recipe, and definitely not
> poky-
> > > image.bbclass.
> > then? Is it possible to create .bbappend kind of file for .bbclass which
> > can append the information or I have to duplicate
> toolchain-script.bbclass
> > in my layer?
>
> Sure, you can add the script append and the additional TOOLCHAIN_HOST_TASK
> items in an additional bbclass in your layer and then inherit that in your
> image recipe; just don't require meta-toolchain.bb because that has other
> side-effects.
>
> > >>What version of the build system are you using?
> >
> > I am using poky danny (8.0.2)
>
> OK, in that case why are you using poky-image.bbclass? That was replaced by
> core-image.bbclass in the edison release if I recall correctly, which was
> quite a while ago.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #1.2: Type: text/html, Size: 2483 bytes --]

[-- Attachment #2: poky-image.bb --]
[-- Type: application/octet-stream, Size: 3297 bytes --]

inherit poky-image

TOOLCHAIN_HOST_TASK += "nativesdk-packagegroup-qte-toolchain-host"
TOOLCHAIN_OUTPUTNAME = "${SDK_NAME}-toolchain-qte-${DISTRO_VERSION}"
TOOLCHAIN_OUTPUTNAME_TAG = "${SDK_NAME}-toolchain-qte-${DISTRO_VERSION}-${GIT_TAG_VERSION}"

QT_DIR_NAME = "qtopia"
QT_TOOLS_PREFIX = "${SDKPATHNATIVE}${bindir_nativesdk}"

IMAGE_NAME="${IMAGE_BASENAME}-${MACHINE}-${GIT_TAG_VERSION}"

IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP}"

IMAGE_INSTALL_append += "tslib-conf tslib-tests tslib-calibrate iproute2 powertop strace u-boot-fw-utils gdb zip procps alsa-utils-aplay mtd-utils unzip dhcp-client alsa-utils-amixer util-linux-blkid e2fsprogs-mke2fs vorbis-tools qt4-embedded update-modules iotop can-utils gcov-symlinks binutils-symlinks fbgrab kernel-modules kmod evtest lcd-apps coreutils fonts xmlstarlet script"

LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
                    file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

IMAGE_LINGUAS = " "

ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; "

IMAGE_CMD_ubi_prepend(){
	cd ${COREBASE}/meta-platform
	export GIT_TAG_VERSION=`git describe`
	cd -
}

IMAGE_CMD_tar_prepend(){
	cd ${COREBASE}/meta-platform
        export GIT_TAG_VERSION=`git describe`
	cd -
}

do_task(){
	rm -rf ${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}*
}

toolchain_create_sdk_env_script_append() {
    echo 'export OE_QMAKE_CFLAGS="$CFLAGS"' >> $script
    echo 'export OE_QMAKE_CXXFLAGS="$CXXFLAGS"' >> $script
    echo 'export OE_QMAKE_LDFLAGS="$LDFLAGS"' >> $script
    echo 'export OE_QMAKE_CC=${TARGET_PREFIX}gcc' >> $script
    echo 'export OE_QMAKE_CXX=${TARGET_PREFIX}g++' >> $script
    echo 'export OE_QMAKE_LINK=${TARGET_PREFIX}g++' >> $script
    echo 'export OE_QMAKE_AR=${TARGET_PREFIX}ar' >> $script
    echo 'export OE_QMAKE_LIBDIR_QT=${SDKTARGETSYSROOT}/${libdir}' >> $script
    echo 'export OE_QMAKE_INCDIR_QT=${SDKTARGETSYSROOT}/${includedir}/${QT_DIR_NAME}' >> $script
    echo 'export OE_QMAKE_MOC=${QT_TOOLS_PREFIX}/moc4' >> $script
    echo 'export OE_QMAKE_UIC=${QT_TOOLS_PREFIX}/uic4' >> $script
    echo 'export OE_QMAKE_UIC3=${QT_TOOLS_PREFIX}/uic34' >> $script
    echo 'export OE_QMAKE_RCC=${QT_TOOLS_PREFIX}/rcc4' >> $script
    echo 'export OE_QMAKE_QDBUSCPP2XML=${QT_TOOLS_PREFIX}/qdbuscpp2xml4' >> $script
    echo 'export OE_QMAKE_QDBUSXML2CPP=${QT_TOOLS_PREFIX}/qdbusxml2cpp4' >> $script
    echo 'export OE_QMAKE_QT_CONFIG=${SDKTARGETSYSROOT}/${datadir}/${QT_DIR_NAME}/mkspecs/qconfig.pri' >> $script
    echo 'export QMAKESPEC=${SDKTARGETSYSROOT}/${datadir}/${QT_DIR_NAME}/mkspecs/linux-g++' >> $script

    # make a symbolic link to mkspecs for compatibility with Nokia's SDK
    # and QTCreator
    (cd ${SDK_OUTPUT}/${QT_TOOLS_PREFIX}/..; ln -s ${SDKTARGETSYSROOT}/usr/share/qtopia/mkspecs mkspecs;)
}

create_shar_append(){
        cd ${COREBASE}/meta-platform
        export GIT_TAG_VERSION=`git describe`

        # rename cross toolchain with added git version
        mv ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh     ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME_TAG}.sh
}

addtask do_clean before IMAGE_CMD_ubi_prepend
addtask do_clean before COMPRESS_CMD_bz2_prepend
addtask do_task before do_clean

Re: bitbake -c populate_sdk -v poky-image

[Paul Eggleton]

On Wednesday 28 August 2013 13:23:04 Navani Srivastava wrote:
> Following is my image file to generate rootfs image with SDK having Qt
> support..
> I am able to build SDK successfully but on building any Qt application with
> generated SDK getting following error message-
> 
> /opt/poky/1.3.2/sysroots/EBboard-poky-linux-gnueabi//usr/include/qtopia/QtCo
> re/qglobal.h:68:21: fatal error: algorithm: No such file or directory
> compilation terminated.
> make[2]: *** [obj_rel/AdjustedTime.o] Error 1
> 
> Please suggest..

I can't tell from the little amount of the error output you've given but it 
sounds like either standard C++ headers are not installed, or they are but the 
compiler can't find them for some reason.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: bitbake -c populate_sdk -v poky-image

[Navani Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

I just removed qt stuff and tried with the SDK built with 'bitbake -c
populate_sdk poky-image' . I just compiled a simple program which includes
stdio.h, while compiling got error that "stdio.h: No such file or
directory" ..
It seems problem is with SDK generated with it. But I am not able to
understand that if problem is somewhere in declaring the correct
architecture then how rootfs and all other binaries  which got generated by
executing "bitbake poky-image" are working on my target. Even though SDK
generated by "bitbake meta-toolhain-qte" is also working fine..
Need some more research..


On Wed, Aug 28, 2013 at 8:11 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Wednesday 28 August 2013 13:23:04 Navani Srivastava wrote:
> > Following is my image file to generate rootfs image with SDK having Qt
> > support..
> > I am able to build SDK successfully but on building any Qt application
> with
> > generated SDK getting following error message-
> >
> >
> /opt/poky/1.3.2/sysroots/EBboard-poky-linux-gnueabi//usr/include/qtopia/QtCo
> > re/qglobal.h:68:21: fatal error: algorithm: No such file or directory
> > compilation terminated.
> > make[2]: *** [obj_rel/AdjustedTime.o] Error 1
> >
> > Please suggest..
>
> I can't tell from the little amount of the error output you've given but it
> sounds like either standard C++ headers are not installed, or they are but
> the
> compiler can't find them for some reason.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #2: Type: text/html, Size: 2102 bytes --]

Re: bitbake -c populate_sdk -v poky-image

[Navani Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

In order to execute
"bitbake -c populate_sdk poky-image" are we supposed to declare
BUILD_ARCH or SDK_ARCH somewhere in local.conf file?
Yocto Documentation has not mentioned anything like that. Just a doubt as
"bitbake poky-image" is working fine though populate_sdk is giving problem..


On Wed, Aug 28, 2013 at 8:11 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Wednesday 28 August 2013 13:23:04 Navani Srivastava wrote:
> > Following is my image file to generate rootfs image with SDK having Qt
> > support..
> > I am able to build SDK successfully but on building any Qt application
> with
> > generated SDK getting following error message-
> >
> >
> /opt/poky/1.3.2/sysroots/EBboard-poky-linux-gnueabi//usr/include/qtopia/QtCo
> > re/qglobal.h:68:21: fatal error: algorithm: No such file or directory
> > compilation terminated.
> > make[2]: *** [obj_rel/AdjustedTime.o] Error 1
> >
> > Please suggest..
>
> I can't tell from the little amount of the error output you've given but it
> sounds like either standard C++ headers are not installed, or they are but
> the
> compiler can't find them for some reason.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #2: Type: text/html, Size: 1773 bytes --]

Re: bitbake -c populate_sdk -v poky-image

[Paul Eggleton]

On Thursday 29 August 2013 10:11:31 Navani Srivastava wrote:
> In order to execute
> "bitbake -c populate_sdk poky-image" are we supposed to declare
> BUILD_ARCH or SDK_ARCH somewhere in local.conf file?
> Yocto Documentation has not mentioned anything like that. Just a doubt as
> "bitbake poky-image" is working fine though populate_sdk is giving problem..

You should set SDKMACHINE if you need the machine that runs the SDK to be a 
different architecture from the machine that you're running the build on, 
otherwise it will just use the same one.

We're aware the documentation is lacking on -c populate_sdk, and we're 
addressing that in the documentation for the next release.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: bitbake -c populate_sdk -v poky-image

[Navani Srivastava]

[-- Attachment #1.1: Type: text/plain, Size: 1583 bytes --]

>>You should set SDKMACHINE if you need the machine that runs the SDK to be
a
different architecture from the machine
Please find the local.conf file which clearly shows SDKMACHINE is i686 and
I want to build for arm1136 arch.. So MACHINE ??= "EBboard" is given where
EBboard refers to arm1136 architecture..
Not able to find any problem in configurations..

/opt/poky/1.3.2/sysroots/i686-pokysdk-linux/usr/bin/armv6-vfp-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
test.c
test.c:3:19: fatal error: stdio.h: No such file or directory

error shows that I have problem in cross toolchain...  Have yocto ever
faced such kind of issue with populate_sdk before ?


On Thu, Aug 29, 2013 at 1:43 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Thursday 29 August 2013 10:11:31 Navani Srivastava wrote:
> > In order to execute
> > "bitbake -c populate_sdk poky-image" are we supposed to declare
> > BUILD_ARCH or SDK_ARCH somewhere in local.conf file?
> > Yocto Documentation has not mentioned anything like that. Just a doubt as
> > "bitbake poky-image" is working fine though populate_sdk is giving
> problem..
>
> You should set SDKMACHINE if you need the machine that runs the SDK to be a
> different architecture from the machine that you're running the build on,
> otherwise it will just use the same one.
>
> We're aware the documentation is lacking on -c populate_sdk, and we're
> addressing that in the documentation for the next release.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

[-- Attachment #1.2: Type: text/html, Size: 2120 bytes --]

[-- Attachment #2: local.conf --]
[-- Type: application/octet-stream, Size: 9960 bytes --]

#
# This file is your local configuration file and is where all local user settings
# are placed. The comments in this file give some guide to the options a new user
# to the system might want to change but pretty much any configuration option can
# be set in this file. More adventurous users can look at local.conf.extended 
# which contains other examples of configuration which can be placed in this file
# but new users likely won't need any of them initially.
#
# Lines starting with the '#' character are commented out and in some cases the 
# default values are provided as comments to show people example syntax. Enabling
# the option is a question of removing the # character and making any change to the
# variable as required.

#
# Parallelism Options
#
# These two options control how much parallelism BitBake should use. The first 
# option determines how many tasks bitbake should run in parallel:
#
BB_NUMBER_THREADS = "4"
# 
# The second option controls how many processes make should run in parallel when
# running compile tasks:
#
PARALLEL_MAKE = "-j 4"
#
# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
# be appropriate for example.

#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for 
# demonstration purposes:
#
#MACHINE ?= "atom-pc"
#MACHINE ?= "beagleboard"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "routerstationpro"
#
# This sets the default machine to be qemux86 if no other machine is selected:
#MACHINE ??= "qemux86"
MACHINE ??= "EBboard"

#
# Where to place downloads
#
# During a first build the system will download many different source code tarballs
# from various upstream projects. This can take a while, particularly if your network
# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build directory.
#
#DL_DIR ?= "${TOPDIR}/downloads"

#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built output.
# This is done using "shared state" files which can be thought of as cache objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
# from these files if no changes were made to the configuration. If changes were made
# to the configuration, only shared state files where the state was still valid would
# be used (done using checksums).
#
# The default is a sstate-cache directory under TOPDIR.
#
#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

#
# Where to place the build output
#
# This option specifies where the bulk of the building work should be done and
# where BitBake should place its temporary files and output. Keep in mind that
# this includes the extraction and compilation of many applications and the toolchain
# which can use Gigabytes of hard disk space.
#
# The default is a tmp directory under TOPDIR.
#
#TMPDIR = "${TOPDIR}/tmp"

#
# Default policy config
#
# The distribution setting controls which policy settings are used as defaults.
# The default value is fine for general Yocto project use, at least initially.
# Ultimately when creating custom policy, people will likely end up subclassing 
# these defaults.
#
DISTRO ?= "poky"
# As an example of a subclass there is a "bleeding" edge policy configuration
# where many versions are set to the absolute latest code from the upstream 
# source control systems. This is just mentioned here as an example, its not
# useful to most new users.
# DISTRO ?= "poky-bleeding"
SANITY_TESTED_DISTROS += "Ubuntu 12.04.2 LTS"

#
# Package Management configuration
#
# This variable lists which packaging formats to enable. Multiple package backends 
# can be enabled at once and the first item listed in the variable will be used 
# to generate the root filesystems.
# Options are:
#  - 'package_deb' for debian style deb files
#  - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
#  - 'package_rpm' for rpm style packages
# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
# We default to rpm:
#PACKAGE_CLASSES ?= "package_rpm"
PACKAGE_CLASSES ?= "package_ipk"

#
# SDK/ADT target architecture
#
# This variable specified the architecture to build SDK/ADT items for and means
# you can build the SDK packages for architectures other than the machine you are 
# running the build on (i.e. building i686 packages on an x86_64 host._
# Supported values are i686 and x86_64
SDKMACHINE ?= "i686"

#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated 
# images. Some of these options are added to certain image types automatically. The
# variable can contain the following options:
#  "dbg-pkgs"       - add -dbg packages for all installed packages
#                     (adds symbol information for debugging/profiling)
#  "dev-pkgs"       - add -dev packages for all installed packages
#                     (useful if you want to develop against libs in the image)
#  "tools-sdk"      - add development tools (gcc, make, pkgconfig etc.)
#  "tools-debug"    - add debugging tools (gdb, strace)
#  "tools-profile"  - add profiling tools (oprofile, exmap, lttng, valgrind)
#  "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
#  "debug-tweaks"   - make an image suitable for development
#                     e.g. ssh root access has a blank password
# There are other application targets that can be used here too, see
# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
# We default to enabling the debugging tweaks.
EXTRA_IMAGE_FEATURES = "debug-tweaks"

#
# Additional image features
#
# The following is a list of additional classes to use when building images which
# enable extra features. Some available options which can be included in this variable 
# are:
#   - 'buildstats' collect build statistics
#   - 'image-mklibs' to reduce shared library files size for an image
#   - 'image-prelink' in order to prelink the filesystem image
#   - 'image-swab' to perform host system intrusion detection
# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
USER_CLASSES ?= "buildstats image-mklibs image-prelink"

#
# Runtime testing of images
#
# The build system can test booting virtual machine images under qemu (an emulator)
# after any root filesystems are created and run tests against those images. To
# enable this uncomment this line
#IMAGETEST = "qemu"
#
# This variable controls which tests are run against virtual images if enabled
# above. The following would enable bat, boot the test case under the sanity suite
# and perform toolchain tests
#TEST_SCEN = "sanity bat sanity:boot toolchain"
#
# Because of the QEMU booting slowness issue (see bug #646 and #618), the
# autobuilder may suffer a timeout issue when running sanity tests. We introduce
# the variable TEST_SERIALIZE here to reduce the time taken by the sanity tests.
# It is set to 1 by default, which will boot the image and run cases in the same
# image without rebooting or killing the machine instance. If it is set to 0, the
# image will be copied and tested for each case, which will take longer but be
# more precise.
#TEST_SERIALIZE = "1"

#
# Interactive shell configuration
#
# Under certain circumstances the system may need input from you and to do this it 
# can launch an interactive shell. It needs to do this since the build is 
# multithreaded and needs to be able to handle the case where more than one parallel
# process may require the user's attention. The default is iterate over the available
# terminal types to find one that works.
#
# Examples of the occasions this may happen are when resolving patches which cannot
# be applied, to use the devshell or the kernel menuconfig
#
# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
# Note: currently, Konsole support only works for KDE 3.x due to the way
# newer Konsole versions behave
#OE_TERMINAL = "auto"
# By default disable interactive patch resolution (tasks will just fail instead):
PATCHRESOLVE = "noop"

#
# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects which can 
# used to accelerate build time. This variable can be used to configure the system
# to search other mirror locations for these objects before it builds the data itself.
#
# This can be a filesystem directory, or a remote url such as http or ftp. These
# would contain the sstate-cache results from previous builds (possibly from other 
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the 
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
# at the end as shown in the examples below. This will be substituted with the
# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\
#file://.* http://someserver.tld/share/sstate/PATH \n \
#file://.* file:///some/local/dir/sstate/PATH"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"
DEBUG_FLAGS = ""

Re: bitbake -c populate_sdk -v poky-image

[Paul Eggleton]

On Thursday 29 August 2013 13:57:12 Navani Srivastava wrote:
> >>You should set SDKMACHINE if you need the machine that runs the SDK to be
> 
> a
> different architecture from the machine
> Please find the local.conf file which clearly shows SDKMACHINE is i686 and
> I want to build for arm1136 arch.. So MACHINE ??= "EBboard" is given where
> EBboard refers to arm1136 architecture..
> Not able to find any problem in configurations..

OK. I think it's unlikely that that would be able to cause this kind of 
problem anyway.

> /opt/poky/1.3.2/sysroots/i686-pokysdk-linux/usr/bin/armv6-vfp-poky-linux-gnu
> eabi/arm-poky-linux-gnueabi-gcc test.c
> test.c:3:19: fatal error: stdio.h: No such file or directory
> 
> error shows that I have problem in cross toolchain...  Have yocto ever
> faced such kind of issue with populate_sdk before ?

Not that I'm aware of. Could you please file a bug in bugzilla for this? It 
would really help if you had a simple test case we can use to reproduce it 
with the SDK as well.

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre