sdk created with arago fido contains hardcoded paths to build system in setup script

sdk created with arago fido contains hardcoded paths to build system in setup script

[Thomas Kaufmann]

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

Hi I tried to get an answer to this from the TI e2e community, but so far without luck:

https://e2e.ti.com/support/embedded/linux/f/354/p/500188/1811754#1811754

My issue is this:

When I create a SDK for my target platform using arago with the populate_sdk command in bitbake. I receive a self extracting shell script, which unpacks all the rootfs, compilers, libraries and everything. Basically the SDK is working and I am able to develop for my target with it.

One thing bothers me:

in the environment-setup-cortexa8hf-vfp-non-linux-gnueabi file which needs to be sourced before using the SDK, there are some hardcoded paths which point to the linaro toolchain as it is installed on the original system, where I actually build the SDK,

e.g.: export CFLAGS=" -isystem/home/tkaufmann/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include  -fstack-protector -O2 -pipe -g -feliminate-unused-debug-types"

similar things are in CFLAGS, CXXFLAGS, LDFLAGS and CPPFLAGS

The plan was to use the compiler and sysroot as it is available in the SDK. This is working so far for sinple projects without separately installing the linaro toolchain. Why are these linaro based paths in the environment-setup script and how do I get rid of this to not confuse the users of the SDK?

I appreciate your feedback

Regards Thomas

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

Re: sdk created with arago fido contains hardcoded paths to build system in setup script

[Denys Dmytriyenko]

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

On Wed, Mar 23, 2016 at 12:12:08PM +0000, Thomas Kaufmann wrote:
> Hi I tried to get an answer to this from the TI e2e community, but so far 
> without luck:
> 
> https://e2e.ti.com/support/embedded/linux/f/354/p/500188/1811754#1811754
> 
> My issue is this:
> 
> When I create a SDK for my target platform using arago with the populate_sdk 
> command in bitbake. I receive a self extracting shell script, which unpacks 
> all the rootfs, compilers, libraries and everything. Basically the SDK is 
> working and I am able to develop for my target with it.
> 
> One thing bothers me:
> 
> in the environment-setup-cortexa8hf-vfp-non-linux-gnueabi file which needs 
> to be sourced before using the SDK, there are some hardcoded paths which 
> point to the linaro toolchain as it is installed on the original system, 
> where I actually build the SDK,
> 
> e.g.: export CFLAGS=" 
> -isystem/home/tkaufmann/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include 
> -fstack-protector -O2 -pipe -g -feliminate-unused-debug-types"
> 
> similar things are in CFLAGS, CXXFLAGS, LDFLAGS and CPPFLAGS
> 
> The plan was to use the compiler and sysroot as it is available in the SDK. 
> This is working so far for sinple projects without separately installing the 
> linaro toolchain. Why are these linaro based paths in the environment-setup 
> script and how do I get rid of this to not confuse the users of the SDK?
> 
> I appreciate your feedback

Thomas,

Sorry for the delay. I just checked our SDK and there are no hardcoded paths 
in there.

Trying to figure out what's different I see that your setup script is called 
"environment-setup-cortexa8hf-vfp-non-linux-gnueabi" while ours is just simple 
"environment-setup". Also I see you mention populate_sdk in bitbake and now it 
becomes clear - you should be using meta-toolchain-arago-tisdk recipe where 
lots of stuff gets cleanup and configured properly...

Attached is the current environment-setup script from our SDK.

-- 
Denys

[-- Attachment #2: environment-setup --]
[-- Type: text/plain, Size: 3091 bytes --]

SDK_PATH="/tmp/abc"
if [ -z "$ZSH_NAME" ] && [ "x$0" = "x./environment-setup" ]; then
    echo "Error: This script needs to be sourced. Please run as \". ./environment-setup\""
    exit 1
else
    if [ -n "$BASH_SOURCE" ]; then
        SDK_PATH="`dirname $BASH_SOURCE`"
    fi
    SDK_PATH=`readlink -f "$SDK_PATH"`
    export SDK_PATH
fi
export SDK_SYS=x86_64-arago-linux
export REAL_MULTIMACH_TARGET_SYS=cortexa8hf-neon-linux-gnueabi
export TOOLCHAIN_SYS=arm-linux-gnueabihf
export TOOLCHAIN_PREFIX=$TOOLCHAIN_SYS-
export SDK_PATH_NATIVE=$SDK_PATH/sysroots/$SDK_SYS
export SDK_PATH_TARGET=$SDK_PATH/sysroots/$REAL_MULTIMACH_TARGET_SYS
export PATH=$SDK_PATH_NATIVE/usr/bin:$PATH
export CPATH=$SDK_PATH_TARGET/usr/include:$CPATH
export PKG_CONFIG_SYSROOT_DIR=$SDK_PATH_TARGET
export PKG_CONFIG_PATH=$SDK_PATH_TARGET/usr/lib/pkgconfig
export PKG_CONFIG_ALLOW_SYSTEM_LIBS=1
export CONFIG_SITE=$SDK_PATH/site-config-$REAL_MULTIMACH_TARGET_SYS
export CC=${TOOLCHAIN_PREFIX}gcc
export CXX=${TOOLCHAIN_PREFIX}g++
export GDB=${TOOLCHAIN_PREFIX}gdb
export CPP="${TOOLCHAIN_PREFIX}gcc -E"
export NM=${TOOLCHAIN_PREFIX}nm
export AS=${TOOLCHAIN_PREFIX}as
export AR=${TOOLCHAIN_PREFIX}ar
export RANLIB=${TOOLCHAIN_PREFIX}ranlib
export OBJCOPY=${TOOLCHAIN_PREFIX}objcopy
export OBJDUMP=${TOOLCHAIN_PREFIX}objdump
export STRIP=${TOOLCHAIN_PREFIX}strip
export CONFIGURE_FLAGS="--target=arm-linux-gnueabi --host=arm-linux-gnueabi --build=x86_64-linux --with-libtool-sysroot=$SDK_PATH_TARGET"
export CPPFLAGS=" -march=armv7-a -marm -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=$SDK_PATH_TARGET"
export CFLAGS="$CPPFLAGS"
export CXXFLAGS="$CPPFLAGS"
export LDFLAGS=" --sysroot=$SDK_PATH_TARGET"
export OECORE_NATIVE_SYSROOT=$SDK_PATH_NATIVE
export OECORE_TARGET_SYSROOT=$SDK_PATH_TARGET
export OECORE_ACLOCAL_OPTS="-I $SDK_PATH_NATIVE/usr/share/aclocal"
export OECORE_DISTRO_VERSION="2016.03"
export OECORE_SDK_VERSION="2016.03"
export PS1="\[\e[32;1m\][linux-devkit]\[\e[0m\]:\w> "
export PATH=$SDK_PATH_NATIVE/usr/bin/qt5:$PATH
export OE_QMAKE_CFLAGS="$CFLAGS"
export OE_QMAKE_CXXFLAGS="$CXXFLAGS"
export OE_QMAKE_LDFLAGS="$LDFLAGS"
export OE_QMAKE_CC=$CC
export OE_QMAKE_CXX=$CXX
export OE_QMAKE_LINK=$CXX
export OE_QMAKE_AR=$AR
export OE_QMAKE_LIBDIR_QT=$SDK_PATH_TARGET/usr/lib
export OE_QMAKE_INCDIR_QT=$SDK_PATH_TARGET/usr/include/qt5
export OE_QMAKE_HOST_BINDIR_QT=$SDK_PATH_NATIVE/usr/bin/qt5/
export OE_QMAKE_MOC=$SDK_PATH_NATIVE/usr/bin/qt5/moc
export OE_QMAKE_UIC=$SDK_PATH_NATIVE/usr/bin/qt5/uic
export OE_QMAKE_UIC3=$SDK_PATH_NATIVE/usr/bin/qt5/uic3
export OE_QMAKE_RCC=$SDK_PATH_NATIVE/usr/bin/qt5/rcc
export OE_QMAKE_QDBUSCPP2XML=$SDK_PATH_NATIVE/usr/bin/qt5/qdbuscpp2xml
export OE_QMAKE_QDBUSXML2CPP=$SDK_PATH_NATIVE/usr/bin/qt5/qdbusxml2cpp
export OE_QMAKE_QT_CONFIG=$SDK_PATH_TARGET/usr/lib/qt5/mkspecs/qconfig.pri
export OE_QMAKE_STRIP="echo"
export QMAKESPEC=$SDK_PATH_TARGET/usr/lib/qt5/mkspecs/linux-oe-g++
export QMAKE_DEFAULT_LIBDIRS=${QT_QMAKE_LIBDIR_QT}
export QMAKE_DEFAULT_INCDIRS=${QT_QMAKE_INCDIR_QT}

Re: sdk created with arago fido contains hardcoded paths to build system in setup script

[Thomas Kaufmann]

Hi Denys

Thank you so much for this hint, I think it pointed me to the right direction.
I based an own sdk and toolchain recipe on meta-toolchain-arago*.
It took me some time to ge rid of the unneeded stuff, but now it bakes.

Also, I now base my images arago-base-minimal instead of core-image-minimal.

One issue remains, the sw_mainfest target() task fails, I think because of a non expanded shell variable.
In the log it looks for a file with ${image} in the name. So all varaibles except one are expanded in the call.
So for the time being I commented out most of sw_mainfest target() in tisdk_image.bbclass.

Another strange behavior is, about every second time I bitbake it parses linux-ti-staging, which I don't use and I did not find the relevant reference to it so far.

Regards Thomas

> -----Original Message-----
> From: Denys Dmytriyenko [mailto:denys@ti.com]
> Sent: Thursday, April 14, 2016 7:33 PM
> To: Thomas Kaufmann <Thomas.Kaufmann@duagon.com>
> Cc: meta-arago@arago-project.org
> Subject: Re: [meta-arago] sdk created with arago fido contains hardcoded
> paths to build system in setup script
> 
> On Wed, Mar 23, 2016 at 12:12:08PM +0000, Thomas Kaufmann wrote:
> > Hi I tried to get an answer to this from the TI e2e community, but so
> > far without luck:
> >
> >
> https://e2e.ti.com/support/embedded/linux/f/354/p/500188/1811754#1811
> 7
> > 54
> >
> > My issue is this:
> >
> > When I create a SDK for my target platform using arago with the
> > populate_sdk command in bitbake. I receive a self extracting shell
> > script, which unpacks all the rootfs, compilers, libraries and
> > everything. Basically the SDK is working and I am able to develop for my
> target with it.
> >
> > One thing bothers me:
> >
> > in the environment-setup-cortexa8hf-vfp-non-linux-gnueabi file which
> > needs to be sourced before using the SDK, there are some hardcoded
> > paths which point to the linaro toolchain as it is installed on the
> > original system, where I actually build the SDK,
> >
> > e.g.: export CFLAGS="
> > -isystem/home/tkaufmann/gcc-linaro-4.9-2015.05-x86_64_arm-linux-
> gnueab
> > ihf/arm-linux-gnueabihf/include -fstack-protector -O2 -pipe -g
> > -feliminate-unused-debug-types"
> >
> > similar things are in CFLAGS, CXXFLAGS, LDFLAGS and CPPFLAGS
> >
> > The plan was to use the compiler and sysroot as it is available in the SDK.
> > This is working so far for sinple projects without separately
> > installing the linaro toolchain. Why are these linaro based paths in
> > the environment-setup script and how do I get rid of this to not confuse
> the users of the SDK?
> >
> > I appreciate your feedback
> 
> Thomas,
> 
> Sorry for the delay. I just checked our SDK and there are no hardcoded paths
> in there.
> 
> Trying to figure out what's different I see that your setup script is called
> "environment-setup-cortexa8hf-vfp-non-linux-gnueabi" while ours is just
> simple "environment-setup". Also I see you mention populate_sdk in
> bitbake and now it becomes clear - you should be using meta-toolchain-
> arago-tisdk recipe where lots of stuff gets cleanup and configured properly...
> 
> Attached is the current environment-setup script from our SDK.
> 
> --
> Denys

Re: sdk created with arago fido contains hardcoded paths to build system in setup script

[Thomas Kaufmann]

Hi again

Just a quick followup. The problems with non expanded variables vanished, after I cleaned out my work directory and rebuilt everything.
The linux-ti-staging is still drawn into my build occasionally, I don't really understand why. But for now I think its fine.

Regards Thomas

> -----Original Message-----
> From: Thomas Kaufmann
> Sent: Friday, April 22, 2016 6:26 PM
> To: 'Denys Dmytriyenko' <denys@ti.com>
> Cc: meta-arago@arago-project.org
> Subject: RE: [meta-arago] sdk created with arago fido contains hardcoded
> paths to build system in setup script
> 
> Hi Denys
> 
> Thank you so much for this hint, I think it pointed me to the right direction.
> I based an own sdk and toolchain recipe on meta-toolchain-arago*.
> It took me some time to ge rid of the unneeded stuff, but now it bakes.
> 
> Also, I now base my images arago-base-minimal instead of core-image-
> minimal.
> 
> One issue remains, the sw_mainfest target() task fails, I think because of a
> non expanded shell variable.
> In the log it looks for a file with ${image} in the name. So all varaibles except
> one are expanded in the call.
> So for the time being I commented out most of sw_mainfest target() in
> tisdk_image.bbclass.
> 
> Another strange behavior is, about every second time I bitbake it parses
> linux-ti-staging, which I don't use and I did not find the relevant reference to
> it so far.
> 
> Regards Thomas
> 
> > -----Original Message-----
> > From: Denys Dmytriyenko [mailto:denys@ti.com]
> > Sent: Thursday, April 14, 2016 7:33 PM
> > To: Thomas Kaufmann <Thomas.Kaufmann@duagon.com>
> > Cc: meta-arago@arago-project.org
> > Subject: Re: [meta-arago] sdk created with arago fido contains
> > hardcoded paths to build system in setup script
> >
> > On Wed, Mar 23, 2016 at 12:12:08PM +0000, Thomas Kaufmann wrote:
> > > Hi I tried to get an answer to this from the TI e2e community, but
> > > so far without luck:
> > >
> > >
> >
> https://e2e.ti.com/support/embedded/linux/f/354/p/500188/1811754#1811
> > 7
> > > 54
> > >
> > > My issue is this:
> > >
> > > When I create a SDK for my target platform using arago with the
> > > populate_sdk command in bitbake. I receive a self extracting shell
> > > script, which unpacks all the rootfs, compilers, libraries and
> > > everything. Basically the SDK is working and I am able to develop
> > > for my
> > target with it.
> > >
> > > One thing bothers me:
> > >
> > > in the environment-setup-cortexa8hf-vfp-non-linux-gnueabi file which
> > > needs to be sourced before using the SDK, there are some hardcoded
> > > paths which point to the linaro toolchain as it is installed on the
> > > original system, where I actually build the SDK,
> > >
> > > e.g.: export CFLAGS="
> > > -isystem/home/tkaufmann/gcc-linaro-4.9-2015.05-x86_64_arm-linux-
> > gnueab
> > > ihf/arm-linux-gnueabihf/include -fstack-protector -O2 -pipe -g
> > > -feliminate-unused-debug-types"
> > >
> > > similar things are in CFLAGS, CXXFLAGS, LDFLAGS and CPPFLAGS
> > >
> > > The plan was to use the compiler and sysroot as it is available in the SDK.
> > > This is working so far for sinple projects without separately
> > > installing the linaro toolchain. Why are these linaro based paths in
> > > the environment-setup script and how do I get rid of this to not
> > > confuse
> > the users of the SDK?
> > >
> > > I appreciate your feedback
> >
> > Thomas,
> >
> > Sorry for the delay. I just checked our SDK and there are no hardcoded
> > paths in there.
> >
> > Trying to figure out what's different I see that your setup script is
> > called "environment-setup-cortexa8hf-vfp-non-linux-gnueabi" while ours
> > is just simple "environment-setup". Also I see you mention
> > populate_sdk in bitbake and now it becomes clear - you should be using
> > meta-toolchain- arago-tisdk recipe where lots of stuff gets cleanup and
> configured properly...
> >
> > Attached is the current environment-setup script from our SDK.
> >
> > --
> > Denys