discuss@lists.opencpi.org

OpenCPI Discussion

Issue building OCPI components using new RCC platform based on N310 SDK

James Kulp

Wed, Jul 17, 2019 7:18 PM

Robert,

Ok. Since Ettus SDKs are certainly something we need to deal with, I
looked into this carefully.
I had to make some OpenCPI patches to support cross tools that required
extra command line and environment info like these do.
Our previous cross-tools (4 or 5, including some altera/arm and other
xilinx sdk ones) did not require this.
I now have a clean build of all the prereqs and the framework itself
using this tool set.
How/where did you get the kernel headers from Ettus? The OpenCPI kernel
driver is the last software thing to build.

I'll be sending a proper patch in a few days so it can be applied to
release 1.5 (which will be posted in the next day or so).
Thanks for the info on this so we can support this sort of thing better
going forward.

Jim

On 7/16/19 4:54 PM, Munro, Robert M. wrote:

Jim,

Attached here.

I believe it was attached with the original message to show how the environment is being specified to the framework along with request to know any variables that are necessary or incorrect.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp jek@parera.com
Sent: Tuesday, July 16, 2019 4:45 PM
To: Munro, Robert M. Robert.Munro@jhuapl.edu; discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new RCC platform based on N310 SDK

One more request: can you send what you are using for ettus_n310_sdk.mk?
Basically I want to discover where we are sensitive to certain environment settings and should not be.
Our builds go to some length to make sure everything relevant is specified in the file, and nothing depends on the environment.

Thanks.

On 7/15/19 12:52 PM, Munro, Robert M. wrote:

Jim,

It looks like the compilation executable environment variables are being overridden. In the sourced SDK environment the CC, CXX, and LD variables are more than the executable but the OCPI environment does not appear to take in the OcpiCFlags and OcpiCXXFlags that are defined in ettus_n310_sdk.mk.

Attached output from the env and printenv commands.

The install-ad9361.sh script was found and followed to generate the required library for assets project compilation. The script build/build-opencpi.sh ettus_n310-sdk was run in an attempt to build the entire framework but it failed when attempting to build its first application with errors stating that ld is unable to find crt*.o and multiple libraries that it is attempting to link.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp jek@parera.com
Sent: Monday, July 15, 2019 10:46 AM
To: Munro, Robert M. Robert.Munro@jhuapl.edu;
discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using
new RCC platform based on N310 SDK

Yes the compiler flags are the issue - I'm just trying to figure out where they are coming from.

Prerequisite build scripts are in three places:

Framework prerequisites in build/prerequisites 2. Per-project prerequisites in the prerequisites subdirectory of projects 3. Per-platform prerequisites (like installing a cross-compiler), in the rcc platform's directory.

On 7/15/19 10:34 AM, Munro, Robert M. wrote:

Jim,

Agreed that the difference between the calls from within install-prerequisites.sh and direct is the environment being used. It's likely the important difference being the parameters passed to gcc and g++ applications shown as the additional '-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi' in the direct call. I can work on posting a more complete environment listing, but suspect this difference will be important.

Does the install-prerequisites.sh script override the $CC and $CXX environment variables which removes the additional flags? I believed that by specifying the additional flags in the ettus_n310_sdk.mk they would be part of the environment as they are when compiling projects using 'ocpidev build project ... -rcc-platform ettus_n310_sdk' .

The build/autotools components completed a build manually with some modifications to autotools/gen/configure. The lines where -Werror=null-dereference and -Werror=maybe-uninitialized are added to compiler flag lists needed to be commented. I was not sure how to correctly remove the compilation flags in this case.

Any changes to compilation flags are in the .mk file for the platform,
including overriding defaults.

But those flags (the "error" ones) should only be used with framework
code which is clean for them.

Obviously we are interested in seeing whatever patches you found as
required.

Where are the compilation steps required for the ad9361 library described? That prerequisite is currently preventing the compilation of the assets project.

Thanks,
Robert Munro

-----Original Message-----
From: discuss discuss-bounces@lists.opencpi.org On Behalf Of James
Kulp
Sent: Monday, July 15, 2019 8:52 AM
To: discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using
new RCC platform based on N310 SDK

Hi Robert,

Thanks for the report.
So the configure commands are the same in both cases, but are run in different environments.
Perhaps you could dump the environment along with the set -x

Jim

On 7/12/19 5:53 PM, Munro, Robert M. wrote:

OCPI Development Team,

An Ettus N310 SDK environment is being integrated into the OCPI build environment to enable building software for the N310 target. The RCC platform has been set up and the core project appears to build successfully using 'ocpidev build project projects/core -rcc -rcc-platform ettus_n310_sdk'.

When attempting to build the assets project the compiler throws an error when it doesn't find some libraries from the prerequisites. I have attempted using the command 'build/install-prerequisites.sh ettus_n310_sdk' to build and install all required prerequisites, but this fails in the configure operation of gmp. By navigating to the prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and running the prescribed configure, make, make install commands the build completes without error. To see the difference between the two commands 'set +x .. set -x' was added around the configure command in build/prerequisites/gmp/install-gmp.sh .

Failing configure command:
../configure --host=arm-oe-linux-gnueabi
--prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp
--exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et
tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic

Failing configure output:
checking whether
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-
li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking
compiler
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-
li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g
-feliminate-unused-debug-types ... no
configure: error: could not find a working compiler, see config.log
for details

Working configure command:
../configure --host=arm-oe-linux-gnueabi
--prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp
--exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et
tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic

Working configure output:
checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm
-mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux
-g nueabi is gcc... yes checking compiler arm-oe-linux-gnueabi-gcc
-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux
-g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes

Since the install-prerequisites.sh script fails in gmp library, the liquid, lzma, and gtest libraries must be built and succeed using a similar manual approach. The assets project is then able to build several RCC elements until it reaches the ad9361_config_proxy.so where it is looking for the libad9361.a . After searching in similar places as the build steps for the other prerequisites (build/prerequisites/<library>) the appropriate instructions for manually building the ad9361 library are not able to be found. Where are the build steps described for this library?

Likewise the build of the build/autotools/ products using this SDK requires manual configuration and is currently failing to complete.

Is the use of a non-Xilinx SDK unsupported for the framework or are there more elements that can be supplied to the framework to support this use case? A copy of the RCC configuration file is attached for reference.

Thank you,
Robert Munro
-------------- next part -------------- An HTML attachment was
scrubbed...
URL:
<http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach
me nts/20190712/d87a4d9e/attachment.html>
-------------- next part -------------- A non-text attachment was
scrubbed...
Name: ettus_n310_sdk.mk
Type: application/octet-stream
Size: 2431 bytes
Desc: ettus_n310_sdk.mk
URL:
<http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach
me nts/20190712/d87a4d9e/attachment.mk>

discuss mailing list
discuss@lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

Robert, Ok. Since Ettus SDKs are certainly something we need to deal with, I looked into this carefully. I had to make some OpenCPI patches to support cross tools that required extra command line and environment info like these do. Our previous cross-tools (4 or 5, including some altera/arm and other xilinx sdk ones) did not require this. I now have a clean build of all the prereqs and the framework itself using this tool set. How/where did you get the kernel headers from Ettus? The OpenCPI kernel driver is the last software thing to build. I'll be sending a proper patch in a few days so it can be applied to release 1.5 (which will be posted in the next day or so). Thanks for the info on this so we can support this sort of thing better going forward. Jim On 7/16/19 4:54 PM, Munro, Robert M. wrote: > Jim, > > Attached here. > > I believe it was attached with the original message to show how the environment is being specified to the framework along with request to know any variables that are necessary or incorrect. > > Thanks, > Robert Munro > > -----Original Message----- > From: James Kulp <jek@parera.com> > Sent: Tuesday, July 16, 2019 4:45 PM > To: Munro, Robert M. <Robert.Munro@jhuapl.edu>; discuss@lists.opencpi.org > Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new RCC platform based on N310 SDK > > One more request: can you send what you are using for ettus_n310_sdk.mk? > Basically I want to discover where we are sensitive to certain environment settings and should not be. > Our builds go to some length to make sure everything relevant is specified in the file, and nothing depends on the environment. > > Thanks. > > On 7/15/19 12:52 PM, Munro, Robert M. wrote: >> Jim, >> >> It looks like the compilation executable environment variables are being overridden. In the sourced SDK environment the CC, CXX, and LD variables are more than the executable but the OCPI environment does not appear to take in the OcpiCFlags and OcpiCXXFlags that are defined in ettus_n310_sdk.mk. >> >> Attached output from the env and printenv commands. >> >> The install-ad9361.sh script was found and followed to generate the required library for assets project compilation. The script build/build-opencpi.sh ettus_n310-sdk was run in an attempt to build the entire framework but it failed when attempting to build its first application with errors stating that ld is unable to find crt*.o and multiple libraries that it is attempting to link. >> >> Thanks, >> Robert Munro >> >> -----Original Message----- >> From: James Kulp <jek@parera.com> >> Sent: Monday, July 15, 2019 10:46 AM >> To: Munro, Robert M. <Robert.Munro@jhuapl.edu>; >> discuss@lists.opencpi.org >> Subject: Re: [Discuss OpenCPI] Issue building OCPI components using >> new RCC platform based on N310 SDK >> >> Yes the compiler flags are the issue - I'm just trying to figure out where they are coming from. >> >> Prerequisite build scripts are in three places: >> 1. Framework prerequisites in build/prerequisites 2. Per-project prerequisites in the prerequisites subdirectory of projects 3. Per-platform prerequisites (like installing a cross-compiler), in the rcc platform's directory. >> >> >> On 7/15/19 10:34 AM, Munro, Robert M. wrote: >>> Jim, >>> >>> Agreed that the difference between the calls from within install-prerequisites.sh and direct is the environment being used. It's likely the important difference being the parameters passed to gcc and g++ applications shown as the additional '-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi' in the direct call. I can work on posting a more complete environment listing, but suspect this difference will be important. >>> >>> Does the install-prerequisites.sh script override the $CC and $CXX environment variables which removes the additional flags? I believed that by specifying the additional flags in the ettus_n310_sdk.mk they would be part of the environment as they are when compiling projects using 'ocpidev build project ... -rcc-platform ettus_n310_sdk' . >>> >>> The build/autotools components completed a build manually with some modifications to autotools/gen/configure. The lines where -Werror=null-dereference and -Werror=maybe-uninitialized are added to compiler flag lists needed to be commented. I was not sure how to correctly remove the compilation flags in this case. >> Any changes to compilation flags are in the .mk file for the platform, >> including overriding defaults. >> >> But those flags (the "error" ones) should only be used with framework >> code which is clean for them. >> >> Obviously we are interested in seeing whatever patches you found as >> required. >> >>> Where are the compilation steps required for the ad9361 library described? That prerequisite is currently preventing the compilation of the assets project. >>> >>> Thanks, >>> Robert Munro >>> >>> -----Original Message----- >>> From: discuss <discuss-bounces@lists.opencpi.org> On Behalf Of James >>> Kulp >>> Sent: Monday, July 15, 2019 8:52 AM >>> To: discuss@lists.opencpi.org >>> Subject: Re: [Discuss OpenCPI] Issue building OCPI components using >>> new RCC platform based on N310 SDK >>> >>> Hi Robert, >>> >>> Thanks for the report. >>> So the configure commands are the same in both cases, but are run in different environments. >>> Perhaps you could dump the environment along with the set -x >>> >>> Jim >>> >>> >>> On 7/12/19 5:53 PM, Munro, Robert M. wrote: >>>> OCPI Development Team, >>>> >>>> An Ettus N310 SDK environment is being integrated into the OCPI build environment to enable building software for the N310 target. The RCC platform has been set up and the core project appears to build successfully using 'ocpidev build project projects/core -rcc -rcc-platform ettus_n310_sdk'. >>>> >>>> When attempting to build the assets project the compiler throws an error when it doesn't find some libraries from the prerequisites. I have attempted using the command 'build/install-prerequisites.sh ettus_n310_sdk' to build and install all required prerequisites, but this fails in the configure operation of gmp. By navigating to the prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and running the prescribed configure, make, make install commands the build completes without error. To see the difference between the two commands 'set +x .. set -x' was added around the configure command in build/prerequisites/gmp/install-gmp.sh . >>>> >>>> Failing configure command: >>>> ../configure --host=arm-oe-linux-gnueabi >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp >>>> --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic >>>> >>>> Failing configure output: >>>> checking whether >>>> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking >>>> compiler >>>> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g >>>> -feliminate-unused-debug-types ... no >>>> configure: error: could not find a working compiler, see config.log >>>> for details >>>> >>>> Working configure command: >>>> ../configure --host=arm-oe-linux-gnueabi >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp >>>> --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic >>>> >>>> Working configure output: >>>> checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm >>>> -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 >>>> --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux >>>> -g nueabi is gcc... yes checking compiler arm-oe-linux-gnueabi-gcc >>>> -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 >>>> --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux >>>> -g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes >>>> >>>> Since the install-prerequisites.sh script fails in gmp library, the liquid, lzma, and gtest libraries must be built and succeed using a similar manual approach. The assets project is then able to build several RCC elements until it reaches the ad9361_config_proxy.so where it is looking for the libad9361.a . After searching in similar places as the build steps for the other prerequisites (build/prerequisites/<library>) the appropriate instructions for manually building the ad9361 library are not able to be found. Where are the build steps described for this library? >>>> >>>> Likewise the build of the build/autotools/ products using this SDK requires manual configuration and is currently failing to complete. >>>> >>>> Is the use of a non-Xilinx SDK unsupported for the framework or are there more elements that can be supplied to the framework to support this use case? A copy of the RCC configuration file is attached for reference. >>>> >>>> Thank you, >>>> Robert Munro >>>> -------------- next part -------------- An HTML attachment was >>>> scrubbed... >>>> URL: >>>> <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach >>>> me nts/20190712/d87a4d9e/attachment.html> >>>> -------------- next part -------------- A non-text attachment was >>>> scrubbed... >>>> Name: ettus_n310_sdk.mk >>>> Type: application/octet-stream >>>> Size: 2431 bytes >>>> Desc: ettus_n310_sdk.mk >>>> URL: >>>> <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach >>>> me nts/20190712/d87a4d9e/attachment.mk> >>>> _______________________________________________ >>>> discuss mailing list >>>> discuss@lists.opencpi.org >>>> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org >>> _______________________________________________ >>> discuss mailing list >>> discuss@lists.opencpi.org >>> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

Chris Hinkey

Wed, Jul 17, 2019 8:34 PM

I think I am running in to a same/similar problem today with a yocto based
toolchain that requires a environmental script be called prior to using
it.

the way rcc workers are built by calling the compiler executables directly
instead of using the standard variables will likley cause similar build
errors to these when building in both of these instances right?

environment script:

Check for LD_LIBRARY_PATH being set, which can break SDK and generally is

a bad practice

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80

http://xahlee.info/UnixResource_dir/_/ldpath.html

Only disable this check if you are absolutely know what you are doing!

if [ ! -z "$LD_LIBRARY_PATH" ]; then
echo "Your environment is misconfigured, you probably need to 'unset
LD_LIBRARY_PATH'"
echo "but please check why this was set in the first place and that
it's safe to unset."
echo "The SDK will not operate correctly in most cases when
LD_LIBRARY_PATH is set."
echo "For more references see:"
echo "
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80"
echo " http://xahlee.info/UnixResource_dir/_/ldpath.html"
return 1
fi
export SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux
export
PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux-musl:$PATH
export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export
PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig
export CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux
export
OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
export OECORE_ACLOCAL_OPTS="-I
/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export OECORE_BASELIB="lib"
export OECORE_TARGET_ARCH="aarch64"
export OECORE_TARGET_OS="linux"
unset command_not_found_handle
export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT"
export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT"
export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT"
export AS="aarch64-poky-linux-as "
export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT"
export GDB=aarch64-poky-linux-gdb
export STRIP=aarch64-poky-linux-strip
export RANLIB=aarch64-poky-linux-ranlib
export OBJCOPY=aarch64-poky-linux-objcopy
export OBJDUMP=aarch64-poky-linux-objdump
export AR=aarch64-poky-linux-ar
export NM=aarch64-poky-linux-nm
export M4=m4
export TARGET_PREFIX=aarch64-poky-linux-
export CONFIGURE_FLAGS="--target=aarch64-poky-linux
--host=aarch64-poky-linux --build=x86_64-linux
--with-libtool-sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
export CPPFLAGS=""
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
export OECORE_DISTRO_VERSION="2.6.2"
export OECORE_SDK_VERSION="2.6.2"
export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-

Append environment subscripts

if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then
for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/.sh; do
. $envfile
done
fi
if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then
for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/.sh; do
. $envfile
done
fi

On Wed, Jul 17, 2019 at 3:19 PM James Kulp jek@parera.com wrote:

Robert,

Jim

On 7/16/19 4:54 PM, Munro, Robert M. wrote:

Jim,

Attached here.

I believe it was attached with the original message to show how the

environment is being specified to the framework along with request to know
any variables that are necessary or incorrect.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp jek@parera.com
Sent: Tuesday, July 16, 2019 4:45 PM
To: Munro, Robert M. Robert.Munro@jhuapl.edu;

discuss@lists.opencpi.org

Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new

RCC platform based on N310 SDK

One more request: can you send what you are using for ettus_n310_sdk.mk

Basically I want to discover where we are sensitive to certain

environment settings and should not be.

Our builds go to some length to make sure everything relevant is

specified in the file, and nothing depends on the environment.

Thanks.

On 7/15/19 12:52 PM, Munro, Robert M. wrote:

Jim,

It looks like the compilation executable environment variables are

being overridden. In the sourced SDK environment the CC, CXX, and LD
variables are more than the executable but the OCPI environment does not
appear to take in the OcpiCFlags and OcpiCXXFlags that are defined in
ettus_n310_sdk.mk.

Attached output from the env and printenv commands.

The install-ad9361.sh script was found and followed to generate the

required library for assets project compilation. The script
build/build-opencpi.sh ettus_n310-sdk was run in an attempt to build the
entire framework but it failed when attempting to build its first
application with errors stating that ld is unable to find crt*.o and
multiple libraries that it is attempting to link.

Thanks,
Robert Munro

Yes the compiler flags are the issue - I'm just trying to figure out

where they are coming from.

Prerequisite build scripts are in three places:

Framework prerequisites in build/prerequisites 2. Per-project

prerequisites in the prerequisites subdirectory of projects 3. Per-platform
prerequisites (like installing a cross-compiler), in the rcc platform's
directory.

On 7/15/19 10:34 AM, Munro, Robert M. wrote:

Jim,

Agreed that the difference between the calls from within

install-prerequisites.sh and direct is the environment being used. It's
likely the important difference being the parameters passed to gcc and g++
applications shown as the additional '-march=armv7-a -marm -mfpu=neon
-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi'
in the direct call. I can work on posting a more complete environment
listing, but suspect this difference will be important.

Does the install-prerequisites.sh script override the $CC and $CXX

environment variables which removes the additional flags? I believed that
by specifying the additional flags in the ettus_n310_sdk.mk they would be
part of the environment as they are when compiling projects using 'ocpidev
build project ... -rcc-platform ettus_n310_sdk' .

The build/autotools components completed a build manually with some

modifications to autotools/gen/configure. The lines where
-Werror=null-dereference and -Werror=maybe-uninitialized are added to
compiler flag lists needed to be commented. I was not sure how to
correctly remove the compilation flags in this case.

Any changes to compilation flags are in the .mk file for the platform,
including overriding defaults.

But those flags (the "error" ones) should only be used with framework
code which is clean for them.

Obviously we are interested in seeing whatever patches you found as
required.

Where are the compilation steps required for the ad9361 library

described? That prerequisite is currently preventing the compilation of
the assets project.

Thanks,
Robert Munro

Hi Robert,

Thanks for the report.
So the configure commands are the same in both cases, but are run in

different environments.

Perhaps you could dump the environment along with the set -x

Jim

On 7/12/19 5:53 PM, Munro, Robert M. wrote:

OCPI Development Team,

An Ettus N310 SDK environment is being integrated into the OCPI build

environment to enable building software for the N310 target. The RCC
platform has been set up and the core project appears to build successfully
using 'ocpidev build project projects/core -rcc -rcc-platform
ettus_n310_sdk'.

When attempting to build the assets project the compiler throws an

error when it doesn't find some libraries from the prerequisites. I have
attempted using the command 'build/install-prerequisites.sh ettus_n310_sdk'
to build and install all required prerequisites, but this fails in the
configure operation of gmp. By navigating to the
prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and running
the prescribed configure, make, make install commands the build completes
without error. To see the difference between the two commands 'set +x ..
set -x' was added around the configure command in
build/prerequisites/gmp/install-gmp.sh .

Since the install-prerequisites.sh script fails in gmp library, the

liquid, lzma, and gtest libraries must be built and succeed using a similar
manual approach. The assets project is then able to build several RCC
elements until it reaches the ad9361_config_proxy.so where it is looking
for the libad9361.a . After searching in similar places as the build steps
for the other prerequisites (build/prerequisites/<library>) the appropriate
instructions for manually building the ad9361 library are not able to be
found. Where are the build steps described for this library?

Likewise the build of the build/autotools/ products using this SDK

requires manual configuration and is currently failing to complete.

Is the use of a non-Xilinx SDK unsupported for the framework or are

there more elements that can be supplied to the framework to support this
use case? A copy of the RCC configuration file is attached for reference.

discuss mailing list
discuss@lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

I think I am running in to a same/similar problem today with a yocto based toolchain that requires a environmental script be called prior to using it. the way rcc workers are built by calling the compiler executables directly instead of using the standard variables will likley cause similar build errors to these when building in both of these instances right? environment script: # Check for LD_LIBRARY_PATH being set, which can break SDK and generally is a bad practice # http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80 # http://xahlee.info/UnixResource_dir/_/ldpath.html # Only disable this check if you are absolutely know what you are doing! if [ ! -z "$LD_LIBRARY_PATH" ]; then echo "Your environment is misconfigured, you probably need to 'unset LD_LIBRARY_PATH'" echo "but please check why this was set in the first place and that it's safe to unset." echo "The SDK will not operate correctly in most cases when LD_LIBRARY_PATH is set." echo "For more references see:" echo " http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80" echo " http://xahlee.info/UnixResource_dir/_/ldpath.html" return 1 fi export SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux export PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux-musl:$PATH export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT export PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig export CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux export OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux" export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT" export OECORE_ACLOCAL_OPTS="-I /home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal" export OECORE_BASELIB="lib" export OECORE_TARGET_ARCH="aarch64" export OECORE_TARGET_OS="linux" unset command_not_found_handle export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT" export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT" export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT" export AS="aarch64-poky-linux-as " export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT" export GDB=aarch64-poky-linux-gdb export STRIP=aarch64-poky-linux-strip export RANLIB=aarch64-poky-linux-ranlib export OBJCOPY=aarch64-poky-linux-objcopy export OBJDUMP=aarch64-poky-linux-objdump export AR=aarch64-poky-linux-ar export NM=aarch64-poky-linux-nm export M4=m4 export TARGET_PREFIX=aarch64-poky-linux- export CONFIGURE_FLAGS="--target=aarch64-poky-linux --host=aarch64-poky-linux --build=x86_64-linux --with-libtool-sysroot=$SDKTARGETSYSROOT" export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" export CPPFLAGS="" export KCFLAGS="--sysroot=$SDKTARGETSYSROOT" export OECORE_DISTRO_VERSION="2.6.2" export OECORE_SDK_VERSION="2.6.2" export ARCH=arm64 export CROSS_COMPILE=aarch64-poky-linux- # Append environment subscripts if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do . $envfile done fi if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do . $envfile done fi On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek@parera.com> wrote: > Robert, > > Ok. Since Ettus SDKs are certainly something we need to deal with, I > looked into this carefully. > I had to make some OpenCPI patches to support cross tools that required > extra command line and environment info like these do. > Our previous cross-tools (4 or 5, including some altera/arm and other > xilinx sdk ones) did not require this. > I now have a clean build of all the prereqs and the framework itself > using this tool set. > How/where did you get the kernel headers from Ettus? The OpenCPI kernel > driver is the last software thing to build. > > I'll be sending a proper patch in a few days so it can be applied to > release 1.5 (which will be posted in the next day or so). > Thanks for the info on this so we can support this sort of thing better > going forward. > > Jim > > On 7/16/19 4:54 PM, Munro, Robert M. wrote: > > Jim, > > > > Attached here. > > > > I believe it was attached with the original message to show how the > environment is being specified to the framework along with request to know > any variables that are necessary or incorrect. > > > > Thanks, > > Robert Munro > > > > -----Original Message----- > > From: James Kulp <jek@parera.com> > > Sent: Tuesday, July 16, 2019 4:45 PM > > To: Munro, Robert M. <Robert.Munro@jhuapl.edu>; > discuss@lists.opencpi.org > > Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new > RCC platform based on N310 SDK > > > > One more request: can you send what you are using for ettus_n310_sdk.mk > ? > > Basically I want to discover where we are sensitive to certain > environment settings and should not be. > > Our builds go to some length to make sure everything relevant is > specified in the file, and nothing depends on the environment. > > > > Thanks. > > > > On 7/15/19 12:52 PM, Munro, Robert M. wrote: > >> Jim, > >> > >> It looks like the compilation executable environment variables are > being overridden. In the sourced SDK environment the CC, CXX, and LD > variables are more than the executable but the OCPI environment does not > appear to take in the OcpiCFlags and OcpiCXXFlags that are defined in > ettus_n310_sdk.mk. > >> > >> Attached output from the env and printenv commands. > >> > >> The install-ad9361.sh script was found and followed to generate the > required library for assets project compilation. The script > build/build-opencpi.sh ettus_n310-sdk was run in an attempt to build the > entire framework but it failed when attempting to build its first > application with errors stating that ld is unable to find crt*.o and > multiple libraries that it is attempting to link. > >> > >> Thanks, > >> Robert Munro > >> > >> -----Original Message----- > >> From: James Kulp <jek@parera.com> > >> Sent: Monday, July 15, 2019 10:46 AM > >> To: Munro, Robert M. <Robert.Munro@jhuapl.edu>; > >> discuss@lists.opencpi.org > >> Subject: Re: [Discuss OpenCPI] Issue building OCPI components using > >> new RCC platform based on N310 SDK > >> > >> Yes the compiler flags are the issue - I'm just trying to figure out > where they are coming from. > >> > >> Prerequisite build scripts are in three places: > >> 1. Framework prerequisites in build/prerequisites 2. Per-project > prerequisites in the prerequisites subdirectory of projects 3. Per-platform > prerequisites (like installing a cross-compiler), in the rcc platform's > directory. > >> > >> > >> On 7/15/19 10:34 AM, Munro, Robert M. wrote: > >>> Jim, > >>> > >>> Agreed that the difference between the calls from within > install-prerequisites.sh and direct is the environment being used. It's > likely the important difference being the parameters passed to gcc and g++ > applications shown as the additional '-march=armv7-a -marm -mfpu=neon > -mfloat-abi=hard -mcpu=cortex-a9 > --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi' > in the direct call. I can work on posting a more complete environment > listing, but suspect this difference will be important. > >>> > >>> Does the install-prerequisites.sh script override the $CC and $CXX > environment variables which removes the additional flags? I believed that > by specifying the additional flags in the ettus_n310_sdk.mk they would be > part of the environment as they are when compiling projects using 'ocpidev > build project ... -rcc-platform ettus_n310_sdk' . > >>> > >>> The build/autotools components completed a build manually with some > modifications to autotools/gen/configure. The lines where > -Werror=null-dereference and -Werror=maybe-uninitialized are added to > compiler flag lists needed to be commented. I was not sure how to > correctly remove the compilation flags in this case. > >> Any changes to compilation flags are in the .mk file for the platform, > >> including overriding defaults. > >> > >> But those flags (the "error" ones) should only be used with framework > >> code which is clean for them. > >> > >> Obviously we are interested in seeing whatever patches you found as > >> required. > >> > >>> Where are the compilation steps required for the ad9361 library > described? That prerequisite is currently preventing the compilation of > the assets project. > >>> > >>> Thanks, > >>> Robert Munro > >>> > >>> -----Original Message----- > >>> From: discuss <discuss-bounces@lists.opencpi.org> On Behalf Of James > >>> Kulp > >>> Sent: Monday, July 15, 2019 8:52 AM > >>> To: discuss@lists.opencpi.org > >>> Subject: Re: [Discuss OpenCPI] Issue building OCPI components using > >>> new RCC platform based on N310 SDK > >>> > >>> Hi Robert, > >>> > >>> Thanks for the report. > >>> So the configure commands are the same in both cases, but are run in > different environments. > >>> Perhaps you could dump the environment along with the set -x > >>> > >>> Jim > >>> > >>> > >>> On 7/12/19 5:53 PM, Munro, Robert M. wrote: > >>>> OCPI Development Team, > >>>> > >>>> An Ettus N310 SDK environment is being integrated into the OCPI build > environment to enable building software for the N310 target. The RCC > platform has been set up and the core project appears to build successfully > using 'ocpidev build project projects/core -rcc -rcc-platform > ettus_n310_sdk'. > >>>> > >>>> When attempting to build the assets project the compiler throws an > error when it doesn't find some libraries from the prerequisites. I have > attempted using the command 'build/install-prerequisites.sh ettus_n310_sdk' > to build and install all required prerequisites, but this fails in the > configure operation of gmp. By navigating to the > prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and running > the prescribed configure, make, make install commands the build completes > without error. To see the difference between the two commands 'set +x .. > set -x' was added around the configure command in > build/prerequisites/gmp/install-gmp.sh . > >>>> > >>>> Failing configure command: > >>>> ../configure --host=arm-oe-linux-gnueabi > >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp > >>>> --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et > >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic > >>>> > >>>> Failing configure output: > >>>> checking whether > >>>> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- > >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking > >>>> compiler > >>>> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- > >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g > >>>> -feliminate-unused-debug-types ... no > >>>> configure: error: could not find a working compiler, see config.log > >>>> for details > >>>> > >>>> Working configure command: > >>>> ../configure --host=arm-oe-linux-gnueabi > >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp > >>>> --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et > >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic > >>>> > >>>> Working configure output: > >>>> checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm > >>>> -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 > >>>> --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux > >>>> -g nueabi is gcc... yes checking compiler arm-oe-linux-gnueabi-gcc > >>>> -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 > >>>> --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux > >>>> -g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes > >>>> > >>>> Since the install-prerequisites.sh script fails in gmp library, the > liquid, lzma, and gtest libraries must be built and succeed using a similar > manual approach. The assets project is then able to build several RCC > elements until it reaches the ad9361_config_proxy.so where it is looking > for the libad9361.a . After searching in similar places as the build steps > for the other prerequisites (build/prerequisites/<library>) the appropriate > instructions for manually building the ad9361 library are not able to be > found. Where are the build steps described for this library? > >>>> > >>>> Likewise the build of the build/autotools/ products using this SDK > requires manual configuration and is currently failing to complete. > >>>> > >>>> Is the use of a non-Xilinx SDK unsupported for the framework or are > there more elements that can be supplied to the framework to support this > use case? A copy of the RCC configuration file is attached for reference. > >>>> > >>>> Thank you, > >>>> Robert Munro > >>>> -------------- next part -------------- An HTML attachment was > >>>> scrubbed... > >>>> URL: > >>>> <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach > >>>> me nts/20190712/d87a4d9e/attachment.html> > >>>> -------------- next part -------------- A non-text attachment was > >>>> scrubbed... > >>>> Name: ettus_n310_sdk.mk > >>>> Type: application/octet-stream > >>>> Size: 2431 bytes > >>>> Desc: ettus_n310_sdk.mk > >>>> URL: > >>>> <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach > >>>> me nts/20190712/d87a4d9e/attachment.mk> > >>>> _______________________________________________ > >>>> discuss mailing list > >>>> discuss@lists.opencpi.org > >>>> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > >>> _______________________________________________ > >>> discuss mailing list > >>> discuss@lists.opencpi.org > >>> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > > > > _______________________________________________ > discuss mailing list > discuss@lists.opencpi.org > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org >

Munro, Robert M.

Wed, Jul 17, 2019 10:03 PM

Jim,

Thanks for your insight and assistance in using this SDK in the OCPI framework. I believe the Ettus SDKs and more generally the OE framework are likely to become commonplace build systems for embedded architectures due to their flexibility and extendibility.

The kernel source tree that is being used in my development environment was generated using Ettus' N310 docker container and build system that is described here https://github.com/EttusResearch/ettus-docker/tree/master/oe-build using the steps from 'docker run ...' to 'build_imgs_package.sh...' to generate an image. Upon completion there will be kernel-source and kernel-build-artifacts directories in build/tmp-glibc/work-shared/<NI kernel version name>/ . There will also be a folder with all the kernel compilation outputs located in build/tmp-glibc/work/<NI kernel version name>-oe-linux-gnueabi/linux-yocto/<yocto kernel version and git information>/linux-<NI kernel version name>-standard-build/ . I am not familiar enough with the build system to know how to generate only these outputs directly.

Chris,

It looks like your build environment is similar to the Ettus SDK environment. This is not surprising because they both appear to be OpenEmbedded environments.

Thanks,

Robert Munro

From: Chris Hinkey chinkey@geontech.com
Sent: Wednesday, July 17, 2019 4:34 PM
To: James Kulp jek@parera.com
Cc: Munro, Robert M. Robert.Munro@jhuapl.edu; discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new RCC platform based on N310 SDK

Check for LD_LIBRARY_PATH being set, which can break SDK and generally is a bad practice

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80

http://xahlee.info/UnixResource_dir/_/ldpath.html

Only disable this check if you are absolutely know what you are doing!

if [ ! -z "$LD_LIBRARY_PATH" ]; then
echo "Your environment is misconfigured, you probably need to 'unset LD_LIBRARY_PATH'"
echo "but please check why this was set in the first place and that it's safe to unset."
echo "The SDK will not operate correctly in most cases when LD_LIBRARY_PATH is set."
echo "For more references see:"
echo " http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80"
echo " http://xahlee.info/UnixResource_dir/_/ldpath.html"
return 1
fi
export SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux
export PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux-musl:$PATH
export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig
export CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux
export OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
export OECORE_ACLOCAL_OPTS="-I /home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export OECORE_BASELIB="lib"
export OECORE_TARGET_ARCH="aarch64"
export OECORE_TARGET_OS="linux"
unset command_not_found_handle
export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT"
export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT"
export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT"
export AS="aarch64-poky-linux-as "
export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT"
export GDB=aarch64-poky-linux-gdb
export STRIP=aarch64-poky-linux-strip
export RANLIB=aarch64-poky-linux-ranlib
export OBJCOPY=aarch64-poky-linux-objcopy
export OBJDUMP=aarch64-poky-linux-objdump
export AR=aarch64-poky-linux-ar
export NM=aarch64-poky-linux-nm
export M4=m4
export TARGET_PREFIX=aarch64-poky-linux-
export CONFIGURE_FLAGS="--target=aarch64-poky-linux --host=aarch64-poky-linux --build=x86_64-linux --with-libtool-sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
export CPPFLAGS=""
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
export OECORE_DISTRO_VERSION="2.6.2"
export OECORE_SDK_VERSION="2.6.2"
export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-

Append environment subscripts

On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek@parera.com mailto:jek@parera.com> wrote:
Robert,

Jim

On 7/16/19 4:54 PM, Munro, Robert M. wrote:

Jim,

Attached here.

I believe it was attached with the original message to show how the environment is being specified to the framework along with request to know any variables that are necessary or incorrect.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp <jek@parera.com mailto:jek@parera.com>
Sent: Tuesday, July 16, 2019 4:45 PM
To: Munro, Robert M. <Robert.Munro@jhuapl.edu mailto:Robert.Munro@jhuapl.edu>; discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new RCC platform based on N310 SDK

One more request: can you send what you are using for ettus_n310_sdk.mkhttp://ettus_n310_sdk.mk?
Basically I want to discover where we are sensitive to certain environment settings and should not be.
Our builds go to some length to make sure everything relevant is specified in the file, and nothing depends on the environment.

Thanks.

On 7/15/19 12:52 PM, Munro, Robert M. wrote:

Jim,

Attached output from the env and printenv commands.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp <jek@parera.com mailto:jek@parera.com>
Sent: Monday, July 15, 2019 10:46 AM
To: Munro, Robert M. <Robert.Munro@jhuapl.edu mailto:Robert.Munro@jhuapl.edu>;
discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using
new RCC platform based on N310 SDK

Yes the compiler flags are the issue - I'm just trying to figure out where they are coming from.

Prerequisite build scripts are in three places:

Framework prerequisites in build/prerequisites 2. Per-project prerequisites in the prerequisites subdirectory of projects 3. Per-platform prerequisites (like installing a cross-compiler), in the rcc platform's directory.

On 7/15/19 10:34 AM, Munro, Robert M. wrote:

Jim,

Does the install-prerequisites.sh script override the $CC and $CXX environment variables which removes the additional flags? I believed that by specifying the additional flags in the ettus_n310_sdk.mkhttp://ettus_n310_sdk.mk they would be part of the environment as they are when compiling projects using 'ocpidev build project ... -rcc-platform ettus_n310_sdk' .

Any changes to compilation flags are in the .mk file for the platform,
including overriding defaults.

But those flags (the "error" ones) should only be used with framework
code which is clean for them.

Obviously we are interested in seeing whatever patches you found as
required.

Where are the compilation steps required for the ad9361 library described? That prerequisite is currently preventing the compilation of the assets project.

Thanks,
Robert Munro

-----Original Message-----
From: discuss <discuss-bounces@lists.opencpi.org mailto:discuss-bounces@lists.opencpi.org> On Behalf Of James
Kulp
Sent: Monday, July 15, 2019 8:52 AM
To: discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using
new RCC platform based on N310 SDK

Hi Robert,

Thanks for the report.
So the configure commands are the same in both cases, but are run in different environments.
Perhaps you could dump the environment along with the set -x

Jim

On 7/12/19 5:53 PM, Munro, Robert M. wrote:

OCPI Development Team,

Likewise the build of the build/autotools/ products using this SDK requires manual configuration and is currently failing to complete.

Thank you,
Robert Munro
-------------- next part -------------- An HTML attachment was
scrubbed...
URL:
<http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach
me nts/20190712/d87a4d9e/attachment.html>
-------------- next part -------------- A non-text attachment was
scrubbed...
Name: ettus_n310_sdk.mkhttp://ettus_n310_sdk.mk
Type: application/octet-stream
Size: 2431 bytes
Desc: ettus_n310_sdk.mkhttp://ettus_n310_sdk.mk
URL:
<http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach
me nts/20190712/d87a4d9e/attachment.mkhttp://attachment.mk>

discuss mailing list
discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

Jim, Thanks for your insight and assistance in using this SDK in the OCPI framework. I believe the Ettus SDKs and more generally the OE framework are likely to become commonplace build systems for embedded architectures due to their flexibility and extendibility. The kernel source tree that is being used in my development environment was generated using Ettus' N310 docker container and build system that is described here https://github.com/EttusResearch/ettus-docker/tree/master/oe-build using the steps from 'docker run ...' to 'build_imgs_package.sh...' to generate an image. Upon completion there will be kernel-source and kernel-build-artifacts directories in build/tmp-glibc/work-shared/<NI kernel version name>/ . There will also be a folder with all the kernel compilation outputs located in build/tmp-glibc/work/<NI kernel version name>-oe-linux-gnueabi/linux-yocto/<yocto kernel version and git information>/linux-<NI kernel version name>-standard-build/ . I am not familiar enough with the build system to know how to generate only these outputs directly. Chris, It looks like your build environment is similar to the Ettus SDK environment. This is not surprising because they both appear to be OpenEmbedded environments. Thanks, Robert Munro From: Chris Hinkey <chinkey@geontech.com> Sent: Wednesday, July 17, 2019 4:34 PM To: James Kulp <jek@parera.com> Cc: Munro, Robert M. <Robert.Munro@jhuapl.edu>; discuss@lists.opencpi.org Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new RCC platform based on N310 SDK I think I am running in to a same/similar problem today with a yocto based toolchain that requires a environmental script be called prior to using it. the way rcc workers are built by calling the compiler executables directly instead of using the standard variables will likley cause similar build errors to these when building in both of these instances right? environment script: # Check for LD_LIBRARY_PATH being set, which can break SDK and generally is a bad practice # http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80 # http://xahlee.info/UnixResource_dir/_/ldpath.html # Only disable this check if you are absolutely know what you are doing! if [ ! -z "$LD_LIBRARY_PATH" ]; then echo "Your environment is misconfigured, you probably need to 'unset LD_LIBRARY_PATH'" echo "but please check why this was set in the first place and that it's safe to unset." echo "The SDK will not operate correctly in most cases when LD_LIBRARY_PATH is set." echo "For more references see:" echo " http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80" echo " http://xahlee.info/UnixResource_dir/_/ldpath.html" return 1 fi export SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux export PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux-musl:$PATH export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT export PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig export CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux export OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux" export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT" export OECORE_ACLOCAL_OPTS="-I /home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal" export OECORE_BASELIB="lib" export OECORE_TARGET_ARCH="aarch64" export OECORE_TARGET_OS="linux" unset command_not_found_handle export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT" export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT" export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT" export AS="aarch64-poky-linux-as " export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT" export GDB=aarch64-poky-linux-gdb export STRIP=aarch64-poky-linux-strip export RANLIB=aarch64-poky-linux-ranlib export OBJCOPY=aarch64-poky-linux-objcopy export OBJDUMP=aarch64-poky-linux-objdump export AR=aarch64-poky-linux-ar export NM=aarch64-poky-linux-nm export M4=m4 export TARGET_PREFIX=aarch64-poky-linux- export CONFIGURE_FLAGS="--target=aarch64-poky-linux --host=aarch64-poky-linux --build=x86_64-linux --with-libtool-sysroot=$SDKTARGETSYSROOT" export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" export CPPFLAGS="" export KCFLAGS="--sysroot=$SDKTARGETSYSROOT" export OECORE_DISTRO_VERSION="2.6.2" export OECORE_SDK_VERSION="2.6.2" export ARCH=arm64 export CROSS_COMPILE=aarch64-poky-linux- # Append environment subscripts if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do . $envfile done fi if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do . $envfile done fi On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek@parera.com<mailto:jek@parera.com>> wrote: Robert, Ok. Since Ettus SDKs are certainly something we need to deal with, I looked into this carefully. I had to make some OpenCPI patches to support cross tools that required extra command line and environment info like these do. Our previous cross-tools (4 or 5, including some altera/arm and other xilinx sdk ones) did not require this. I now have a clean build of all the prereqs and the framework itself using this tool set. How/where did you get the kernel headers from Ettus? The OpenCPI kernel driver is the last software thing to build. I'll be sending a proper patch in a few days so it can be applied to release 1.5 (which will be posted in the next day or so). Thanks for the info on this so we can support this sort of thing better going forward. Jim On 7/16/19 4:54 PM, Munro, Robert M. wrote: > Jim, > > Attached here. > > I believe it was attached with the original message to show how the environment is being specified to the framework along with request to know any variables that are necessary or incorrect. > > Thanks, > Robert Munro > > -----Original Message----- > From: James Kulp <jek@parera.com<mailto:jek@parera.com>> > Sent: Tuesday, July 16, 2019 4:45 PM > To: Munro, Robert M. <Robert.Munro@jhuapl.edu<mailto:Robert.Munro@jhuapl.edu>>; discuss@lists.opencpi.org<mailto:discuss@lists.opencpi.org> > Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new RCC platform based on N310 SDK > > One more request: can you send what you are using for ettus_n310_sdk.mk<http://ettus_n310_sdk.mk>? > Basically I want to discover where we are sensitive to certain environment settings and should not be. > Our builds go to some length to make sure everything relevant is specified in the file, and nothing depends on the environment. > > Thanks. > > On 7/15/19 12:52 PM, Munro, Robert M. wrote: >> Jim, >> >> It looks like the compilation executable environment variables are being overridden. In the sourced SDK environment the CC, CXX, and LD variables are more than the executable but the OCPI environment does not appear to take in the OcpiCFlags and OcpiCXXFlags that are defined in ettus_n310_sdk.mk<http://ettus_n310_sdk.mk>. >> >> Attached output from the env and printenv commands. >> >> The install-ad9361.sh script was found and followed to generate the required library for assets project compilation. The script build/build-opencpi.sh ettus_n310-sdk was run in an attempt to build the entire framework but it failed when attempting to build its first application with errors stating that ld is unable to find crt*.o and multiple libraries that it is attempting to link. >> >> Thanks, >> Robert Munro >> >> -----Original Message----- >> From: James Kulp <jek@parera.com<mailto:jek@parera.com>> >> Sent: Monday, July 15, 2019 10:46 AM >> To: Munro, Robert M. <Robert.Munro@jhuapl.edu<mailto:Robert.Munro@jhuapl.edu>>; >> discuss@lists.opencpi.org<mailto:discuss@lists.opencpi.org> >> Subject: Re: [Discuss OpenCPI] Issue building OCPI components using >> new RCC platform based on N310 SDK >> >> Yes the compiler flags are the issue - I'm just trying to figure out where they are coming from. >> >> Prerequisite build scripts are in three places: >> 1. Framework prerequisites in build/prerequisites 2. Per-project prerequisites in the prerequisites subdirectory of projects 3. Per-platform prerequisites (like installing a cross-compiler), in the rcc platform's directory. >> >> >> On 7/15/19 10:34 AM, Munro, Robert M. wrote: >>> Jim, >>> >>> Agreed that the difference between the calls from within install-prerequisites.sh and direct is the environment being used. It's likely the important difference being the parameters passed to gcc and g++ applications shown as the additional '-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi' in the direct call. I can work on posting a more complete environment listing, but suspect this difference will be important. >>> >>> Does the install-prerequisites.sh script override the $CC and $CXX environment variables which removes the additional flags? I believed that by specifying the additional flags in the ettus_n310_sdk.mk<http://ettus_n310_sdk.mk> they would be part of the environment as they are when compiling projects using 'ocpidev build project ... -rcc-platform ettus_n310_sdk' . >>> >>> The build/autotools components completed a build manually with some modifications to autotools/gen/configure. The lines where -Werror=null-dereference and -Werror=maybe-uninitialized are added to compiler flag lists needed to be commented. I was not sure how to correctly remove the compilation flags in this case. >> Any changes to compilation flags are in the .mk file for the platform, >> including overriding defaults. >> >> But those flags (the "error" ones) should only be used with framework >> code which is clean for them. >> >> Obviously we are interested in seeing whatever patches you found as >> required. >> >>> Where are the compilation steps required for the ad9361 library described? That prerequisite is currently preventing the compilation of the assets project. >>> >>> Thanks, >>> Robert Munro >>> >>> -----Original Message----- >>> From: discuss <discuss-bounces@lists.opencpi.org<mailto:discuss-bounces@lists.opencpi.org>> On Behalf Of James >>> Kulp >>> Sent: Monday, July 15, 2019 8:52 AM >>> To: discuss@lists.opencpi.org<mailto:discuss@lists.opencpi.org> >>> Subject: Re: [Discuss OpenCPI] Issue building OCPI components using >>> new RCC platform based on N310 SDK >>> >>> Hi Robert, >>> >>> Thanks for the report. >>> So the configure commands are the same in both cases, but are run in different environments. >>> Perhaps you could dump the environment along with the set -x >>> >>> Jim >>> >>> >>> On 7/12/19 5:53 PM, Munro, Robert M. wrote: >>>> OCPI Development Team, >>>> >>>> An Ettus N310 SDK environment is being integrated into the OCPI build environment to enable building software for the N310 target. The RCC platform has been set up and the core project appears to build successfully using 'ocpidev build project projects/core -rcc -rcc-platform ettus_n310_sdk'. >>>> >>>> When attempting to build the assets project the compiler throws an error when it doesn't find some libraries from the prerequisites. I have attempted using the command 'build/install-prerequisites.sh ettus_n310_sdk' to build and install all required prerequisites, but this fails in the configure operation of gmp. By navigating to the prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and running the prescribed configure, make, make install commands the build completes without error. To see the difference between the two commands 'set +x .. set -x' was added around the configure command in build/prerequisites/gmp/install-gmp.sh . >>>> >>>> Failing configure command: >>>> ../configure --host=arm-oe-linux-gnueabi >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp >>>> --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic >>>> >>>> Failing configure output: >>>> checking whether >>>> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking >>>> compiler >>>> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g >>>> -feliminate-unused-debug-types ... no >>>> configure: error: could not find a working compiler, see config.log >>>> for details >>>> >>>> Working configure command: >>>> ../configure --host=arm-oe-linux-gnueabi >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp >>>> --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic >>>> >>>> Working configure output: >>>> checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm >>>> -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 >>>> --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux >>>> -g nueabi is gcc... yes checking compiler arm-oe-linux-gnueabi-gcc >>>> -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 >>>> --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux >>>> -g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes >>>> >>>> Since the install-prerequisites.sh script fails in gmp library, the liquid, lzma, and gtest libraries must be built and succeed using a similar manual approach. The assets project is then able to build several RCC elements until it reaches the ad9361_config_proxy.so where it is looking for the libad9361.a . After searching in similar places as the build steps for the other prerequisites (build/prerequisites/<library>) the appropriate instructions for manually building the ad9361 library are not able to be found. Where are the build steps described for this library? >>>> >>>> Likewise the build of the build/autotools/ products using this SDK requires manual configuration and is currently failing to complete. >>>> >>>> Is the use of a non-Xilinx SDK unsupported for the framework or are there more elements that can be supplied to the framework to support this use case? A copy of the RCC configuration file is attached for reference. >>>> >>>> Thank you, >>>> Robert Munro >>>> -------------- next part -------------- An HTML attachment was >>>> scrubbed... >>>> URL: >>>> <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach >>>> me nts/20190712/d87a4d9e/attachment.html> >>>> -------------- next part -------------- A non-text attachment was >>>> scrubbed... >>>> Name: ettus_n310_sdk.mk<http://ettus_n310_sdk.mk> >>>> Type: application/octet-stream >>>> Size: 2431 bytes >>>> Desc: ettus_n310_sdk.mk<http://ettus_n310_sdk.mk> >>>> URL: >>>> <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach >>>> me nts/20190712/d87a4d9e/attachment.mk<http://attachment.mk>> >>>> _______________________________________________ >>>> discuss mailing list >>>> discuss@lists.opencpi.org<mailto:discuss@lists.opencpi.org> >>>> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org >>> _______________________________________________ >>> discuss mailing list >>> discuss@lists.opencpi.org<mailto:discuss@lists.opencpi.org> >>> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org _______________________________________________ discuss mailing list discuss@lists.opencpi.org<mailto:discuss@lists.opencpi.org> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

James Kulp

Thu, Jul 18, 2019 11:51 AM

An HTML attachment was scrubbed...
URL: http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attachments/20190718/29d321e8/attachment.html

An HTML attachment was scrubbed... URL: <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attachments/20190718/29d321e8/attachment.html>

James Kulp

Thu, Jul 18, 2019 12:07 PM

On 7/17/19 6:03 PM, Munro, Robert M. wrote:

Jim,

Thanks for your insight and assistance in using this SDK in the OCPI
framework. I believe the Ettus SDKs and more generally the OE
framework are likely to become commonplace build systems for embedded
architectures due to their flexibility and extendibility.

I agree. Sad but true. Their SDKs are clearly not designed to coexist
with any other tools.

Many people expect to do ./configure && make, and ./configure --help
suggests adding compiler flags using a CFLAGS argument, but when you use
the OE SDK you have to know that CFLAGS is already set in the
environment, and you must do something like CFLAGS="$CFLAGS --special-flag".

And people that write Makefiles think that they use CFLAGS to set
compilation flags beyond the defaults of the compiler, but OE SDK
requires you to remember that it sets environment variables outside of
Make and make files.

And people that write Makefiles that create both host binaries and cross
binaries can't since the environment variables set by the SDK can trash
the host compilation.

Basically their design decisions conflict with our multi-target build
environment.

But we can deal with it. It boils down to:

all prerequisite build scripts (mostly ./configure && make) must be
aware of the unusual environment behavior
all uses of OE cross-tools must be wrapped in a two line script that
sources the environment setup locally

The kernel source tree that is being used in my development
environment was generated using Ettus' N310 docker container and build
system that is described here
https://github.com/EttusResearch/ettus-docker/tree/master/oe-build
using the steps from 'docker run ...' to 'build_imgs_package.sh...' to
generate an image. Upon completion there will be kernel-source and
kernel-build-artifacts directories in build/tmp-glibc/work-shared/<NI kernel version name>/ . There will also be a folder with all the
kernel compilation outputs located in build/tmp-glibc/work/<NI kernel version name>-oe-linux-gnueabi/linux-yocto/<yocto kernel version and git information>/linux-<NI kernel version name>-standard-build/ . I
am not familiar enough with the build system to know how to generate
only these outputs directly.

Right - we essentially use the Redhat/Centos model and expect to
install/download/create a "kernel-headers" directory or tarball for the
kernel in question.

For grins, the environment delta that the SDK environment setup creates is:

AR=arm-oe-linux-gnueabi-ar
ARCH=arm
AS=arm-oe-linux-gnueabi-as
CC=arm-oe-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon

-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi

CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types

CONFIG_SITE=/home/jek/mac/Ettus/sdk/site-config-cortexa9hf-neon-oe-linux-gnueabi

CONFIGURE_FLAGS=--target=arm-oe-linux-gnueabi

--host=arm-oe-linux-gnueabi --build=x86_64-linux
--with-libtool-sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi

CPP=arm-oe-linux-gnueabi-gcc -E -march=armv7-a -marm -mfpu=neon

-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi

CPPFLAGS=
CROSS_COMPILE=arm-oe-linux-gnueabi-
CXX=arm-oe-linux-gnueabi-g++ -march=armv7-a -marm -mfpu=neon

-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi

CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
GDB=arm-oe-linux-gnueabi-gdb

KCFLAGS=--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi

LD=arm-oe-linux-gnueabi-ld

--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi

LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
M4=m4
NM=arm-oe-linux-gnueabi-nm
OBJCOPY=arm-oe-linux-gnueabi-objcopy
OBJDUMP=arm-oe-linux-gnueabi-objdump
OECORE_ACLOCAL_OPTS=-I

/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/share/aclocal

OECORE_DISTRO_VERSION=2018.04

OECORE_NATIVE_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux

OECORE_SDK_VERSION=nodistro.0

OECORE_TARGET_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi

PKG_CONFIG_PATH=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/pkgconfig:/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/share/pkgconfig

PKG_CONFIG_SYSROOT_DIR=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi

RANLIB=arm-oe-linux-gnueabi-ranlib

SDKTARGETSYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi

STRIP=arm-oe-linux-gnueabi-strip
TARGET_PREFIX=arm-oe-linux-gnueabi-

<
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.local/bin:/home/jek/bin

PATH=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/sbin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/sbin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/../x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musl:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.local/bin:/home/jek/bin

Chris,

It looks like your build environment is similar to the Ettus SDK
environment. This is not surprising because they both appear to be
OpenEmbedded environments.

Thanks,

Robert Munro

*From:*Chris Hinkey chinkey@geontech.com
Sent: Wednesday, July 17, 2019 4:34 PM
To: James Kulp jek@parera.com
Cc: Munro, Robert M. Robert.Munro@jhuapl.edu;
discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using
new RCC platform based on N310 SDK

I think I am running in to a same/similar problem today with a yocto
based toolchain that requires a environmental script be called prior
to using it.

the way rcc workers are built by calling the compiler executables
directly instead of using the standard variables will likley cause
similar build errors to these when building in both of these instances
right?

environment script:

Check for LD_LIBRARY_PATH being set, which can break SDK and

generally is a bad practice

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80

http://xahlee.info/UnixResource_dir/_/ldpath.html

Only disable this check if you are absolutely know what you are doing!

if [ ! -z "$LD_LIBRARY_PATH" ]; then
echo "Your environment is misconfigured, you probably need to
'unset LD_LIBRARY_PATH'"
echo "but please check why this was set in the first place and
that it's safe to unset."
echo "The SDK will not operate correctly in most cases when
LD_LIBRARY_PATH is set."
echo "For more references see:"
echo "
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80"
echo " http://xahlee.info/UnixResource_dir/_/ldpath.html"
return 1
fi
export
SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux
export
PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux-musl:$PATH
export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export
PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig
export CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux
export
OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
export OECORE_ACLOCAL_OPTS="-I
/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export OECORE_BASELIB="lib"
export OECORE_TARGET_ARCH="aarch64"
export OECORE_TARGET_OS="linux"
unset command_not_found_handle
export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT"
export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT"
export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT"
export AS="aarch64-poky-linux-as "
export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT"
export GDB=aarch64-poky-linux-gdb
export STRIP=aarch64-poky-linux-strip
export RANLIB=aarch64-poky-linux-ranlib
export OBJCOPY=aarch64-poky-linux-objcopy
export OBJDUMP=aarch64-poky-linux-objdump
export AR=aarch64-poky-linux-ar
export NM=aarch64-poky-linux-nm
export M4=m4
export TARGET_PREFIX=aarch64-poky-linux-
export CONFIGURE_FLAGS="--target=aarch64-poky-linux
--host=aarch64-poky-linux --build=x86_64-linux
--with-libtool-sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
export CPPFLAGS=""
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
export OECORE_DISTRO_VERSION="2.6.2"
export OECORE_SDK_VERSION="2.6.2"
export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-

Append environment subscripts

On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek@parera.com
mailto:jek@parera.com> wrote:

 Robert,

 Ok. Since Ettus SDKs are certainly something we need to deal with, I
 looked into this carefully.
 I had to make some OpenCPI patches to support cross tools that
 required
 extra command line and environment info like these do.
 Our previous cross-tools (4 or 5, including some altera/arm and other
 xilinx sdk ones) did not require this.
 I now have a clean build of all the prereqs and the framework itself
 using this tool set.
 How/where did you get the kernel headers from Ettus?  The OpenCPI
 kernel
 driver is the last software thing to build.

 I'll be sending a proper patch in a few days so it can be applied to
 release 1.5 (which will be posted in the next day or so).
 Thanks for the info on this so we can support this sort of thing
 better
 going forward.

 Jim

 On 7/16/19 4:54 PM, Munro, Robert M. wrote:

Jim,

Attached here.

I believe it was attached with the original message to show how

 the environment is being specified to the framework along with
 request to know any variables that are necessary or incorrect.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp <jek@parera.com mailto:jek@parera.com>
Sent: Tuesday, July 16, 2019 4:45 PM
To: Munro, Robert M. <Robert.Munro@jhuapl.edu

 <mailto:Robert.Munro@jhuapl.edu>>; discuss@lists.opencpi.org
 <mailto:discuss@lists.opencpi.org>

Subject: Re: [Discuss OpenCPI] Issue building OCPI components

 using new RCC platform based on N310 SDK

One more request: can you send what you are using for

 ettus_n310_sdk.mk <http://ettus_n310_sdk.mk>?

Basically I want to discover where we are sensitive to certain

 environment settings and should not be.

Our builds go to some length to make sure everything relevant is

 specified in the file, and nothing depends on the environment.

Thanks.

On 7/15/19 12:52 PM, Munro, Robert M. wrote:

Jim,

It looks like the compilation executable environment variables

 are being overridden.  In the sourced SDK environment the CC, CXX,
 and LD variables are more than the executable but the OCPI
 environment does not appear to take in the OcpiCFlags and
 OcpiCXXFlags that are defined in ettus_n310_sdk.mk
 <http://ettus_n310_sdk.mk>.

Attached output from the env and printenv commands.

The install-ad9361.sh script was found and followed to generate

 the required library for assets project compilation.  The script
 build/build-opencpi.sh ettus_n310-sdk was run in an attempt to
 build the entire framework but it failed when attempting to build
 its first application with errors stating that ld is unable to
 find crt*.o and multiple libraries that it is attempting to link.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp <jek@parera.com mailto:jek@parera.com>
Sent: Monday, July 15, 2019 10:46 AM
To: Munro, Robert M. <Robert.Munro@jhuapl.edu

 <mailto:Robert.Munro@jhuapl.edu>>;

discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using
new RCC platform based on N310 SDK

Yes the compiler flags are the issue - I'm just trying to

 figure out where they are coming from.

Prerequisite build scripts are in three places:

Framework prerequisites in build/prerequisites 2.

 Per-project prerequisites in the prerequisites subdirectory of
 projects 3. Per-platform prerequisites (like installing a
 cross-compiler), in the rcc platform's directory.

On 7/15/19 10:34 AM, Munro, Robert M. wrote:

Jim,

Agreed that the difference between the calls from within

 install-prerequisites.sh and direct is the environment being
 used.  It's likely the important difference being the parameters
 passed to gcc and g++ applications shown as the additional
 '-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi'
 in the direct call.  I can work on posting a more complete
 environment listing, but suspect this difference will be important.

Does the install-prerequisites.sh script override the $CC and

 $CXX environment variables which removes the additional flags?  I
 believed that by specifying the additional flags in the
 ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> they would be part of
 the environment as they are when compiling projects using 'ocpidev
 build project ... -rcc-platform ettus_n310_sdk' .

The build/autotools components completed a build manually with

 some modifications to autotools/gen/configure.  The lines where
 -Werror=null-dereference and -Werror=maybe-uninitialized are added
 to compiler flag lists needed to be commented. I was not sure how
 to correctly remove the compilation flags in this case.

Any changes to compilation flags are in the .mk file for the

 platform,

including overriding defaults.

But those flags (the "error" ones) should only be used with

 framework

code which is clean for them.

Obviously we are interested in seeing whatever patches you found as
required.

Where are the compilation steps required for the ad9361

 library described?  That prerequisite is currently preventing the
 compilation of the assets project.

Thanks,
Robert Munro

-----Original Message-----
From: discuss <discuss-bounces@lists.opencpi.org

 <mailto:discuss-bounces@lists.opencpi.org>> On Behalf Of James

Kulp
Sent: Monday, July 15, 2019 8:52 AM
To: discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components

 using

new RCC platform based on N310 SDK

Hi Robert,

Thanks for the report.
So the configure commands are the same in both cases, but are

 run in different environments.

Perhaps you could dump the environment along with the set -x

Jim

On 7/12/19 5:53 PM, Munro, Robert M. wrote:

OCPI Development Team,

An Ettus N310 SDK environment is being integrated into the

 OCPI build environment to enable building software for the N310
 target.  The RCC platform has been set up and the core project
 appears to build successfully using 'ocpidev build project
 projects/core -rcc -rcc-platform ettus_n310_sdk'.

When attempting to build the assets project the compiler

 throws an error when it doesn't find some libraries from the
 prerequisites.  I have attempted using the command
 'build/install-prerequisites.sh ettus_n310_sdk' to build and
 install all required prerequisites, but this fails in the
 configure operation of gmp.  By navigating to the
 prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and
 running the prescribed configure, make, make install commands the
 build completes without error.  To see the difference between the
 two commands 'set +x .. set -x' was added around the configure
 command in build/prerequisites/gmp/install-gmp.sh .

Failing configure command:
../configure --host=arm-oe-linux-gnueabi
--prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp

 --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et

tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic

Failing configure output:
checking whether

 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-

li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking
compiler

 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-

li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g
-feliminate-unused-debug-types ... no
configure: error: could not find a working compiler, see

 config.log

for details

Working configure command:
../configure --host=arm-oe-linux-gnueabi
--prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp

 --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et

tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic

Working configure output:
checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm
-mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9

 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux

-g nueabi is gcc... yes checking compiler

 arm-oe-linux-gnueabi-gcc

-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9

 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux

-g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes

Since the install-prerequisites.sh script fails in gmp

 library, the liquid, lzma, and gtest libraries must be built and
 succeed using a similar manual approach.  The assets project is
 then able to build several RCC elements until it reaches the
 ad9361_config_proxy.so where it is looking for the libad9361.a . 
 After searching in similar places as the build steps for the other
 prerequisites (build/prerequisites/<library>) the appropriate
 instructions for manually building the ad9361 library are not able
 to be found.  Where are the build steps described for this library?

Likewise the build of the build/autotools/ products using

 this SDK requires manual configuration and is currently failing to
 complete.

Is the use of a non-Xilinx SDK unsupported for the framework

 or are there more elements that can be supplied to the framework
 to support this use case?  A copy of the RCC configuration file is
 attached for reference.

Thank you,
Robert Munro
-------------- next part -------------- An HTML attachment was
scrubbed...
URL:

 <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach

me nts/20190712/d87a4d9e/attachment.html>
-------------- next part -------------- A non-text attachment was
scrubbed...
Name: ettus_n310_sdk.mk http://ettus_n310_sdk.mk
Type: application/octet-stream
Size: 2431 bytes
Desc: ettus_n310_sdk.mk http://ettus_n310_sdk.mk
URL:

 <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach

me nts/20190712/d87a4d9e/attachment.mk http://attachment.mk>

discuss mailing list
discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org

 http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

discuss mailing list
discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org

 http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org



 _______________________________________________
 discuss mailing list
 discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org>
 http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

On 7/17/19 6:03 PM, Munro, Robert M. wrote: > > Jim, > > Thanks for your insight and assistance in using this SDK in the OCPI > framework. I believe the Ettus SDKs and more generally the OE > framework are likely to become commonplace build systems for embedded > architectures due to their flexibility and extendibility. > I agree. Sad but true. Their SDKs are clearly not designed to coexist with any other tools. Many people expect to do ./configure && make, and ./configure --help suggests adding compiler flags using a CFLAGS argument, but when you use the OE SDK you have to know that CFLAGS is already set in the environment, and you must do something like CFLAGS="$CFLAGS --special-flag". And people that write Makefiles think that they use CFLAGS to set compilation flags beyond the defaults of the compiler, but OE SDK requires you to remember that it sets environment variables outside of Make and make files. And people that write Makefiles that create both host binaries and cross binaries can't since the environment variables set by the SDK can trash the host compilation. Basically their design decisions conflict with our multi-target build environment. But we can deal with it. It boils down to: - all prerequisite build scripts (mostly ./configure && make) must be aware of the unusual environment behavior - all uses of OE cross-tools must be wrapped in a two line script that sources the environment setup locally > The kernel source tree that is being used in my development > environment was generated using Ettus' N310 docker container and build > system that is described here > https://github.com/EttusResearch/ettus-docker/tree/master/oe-build > using the steps from 'docker run ...' to 'build_imgs_package.sh...' to > generate an image. Upon completion there will be kernel-source and > kernel-build-artifacts directories in build/tmp-glibc/work-shared/<NI > kernel version name>/ . There will also be a folder with all the > kernel compilation outputs located in build/tmp-glibc/work/<NI kernel > version name>-oe-linux-gnueabi/linux-yocto/<yocto kernel version and > git information>/linux-<NI kernel version name>-standard-build/ . I > am not familiar enough with the build system to know how to generate > only these outputs directly. > Right - we essentially use the Redhat/Centos model and expect to install/download/create a "kernel-headers" directory or tarball for the kernel in question. For grins, the environment delta that the SDK environment setup creates is: > > AR=arm-oe-linux-gnueabi-ar > > ARCH=arm > > AS=arm-oe-linux-gnueabi-as > > CC=arm-oe-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon > -mfloat-abi=hard -mcpu=cortex-a9 > --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi > > CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types > > > CONFIG_SITE=/home/jek/mac/Ettus/sdk/site-config-cortexa9hf-neon-oe-linux-gnueabi > > CONFIGURE_FLAGS=--target=arm-oe-linux-gnueabi > --host=arm-oe-linux-gnueabi --build=x86_64-linux > --with-libtool-sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi > > CPP=arm-oe-linux-gnueabi-gcc -E -march=armv7-a -marm -mfpu=neon > -mfloat-abi=hard -mcpu=cortex-a9 > --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi > > CPPFLAGS= > > CROSS_COMPILE=arm-oe-linux-gnueabi- > > CXX=arm-oe-linux-gnueabi-g++ -march=armv7-a -marm -mfpu=neon > -mfloat-abi=hard -mcpu=cortex-a9 > --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi > > CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types > > GDB=arm-oe-linux-gnueabi-gdb > > > KCFLAGS=--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi > > LD=arm-oe-linux-gnueabi-ld > --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi > > LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed > > M4=m4 > > NM=arm-oe-linux-gnueabi-nm > > OBJCOPY=arm-oe-linux-gnueabi-objcopy > > OBJDUMP=arm-oe-linux-gnueabi-objdump > > OECORE_ACLOCAL_OPTS=-I > /home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/share/aclocal > > OECORE_DISTRO_VERSION=2018.04 > > > OECORE_NATIVE_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux > > OECORE_SDK_VERSION=nodistro.0 > > > OECORE_TARGET_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi > > > PKG_CONFIG_PATH=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/pkgconfig:/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/share/pkgconfig > > > PKG_CONFIG_SYSROOT_DIR=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi > > RANLIB=arm-oe-linux-gnueabi-ranlib > > > SDKTARGETSYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gnueabi > > STRIP=arm-oe-linux-gnueabi-strip > > TARGET_PREFIX=arm-oe-linux-gnueabi- > < > PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.local/bin:/home/jek/bin > --- > > > PATH=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/sbin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/sbin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/../x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi:/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musl:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.local/bin:/home/jek/bin > Chris, > > It looks like your build environment is similar to the Ettus SDK > environment. This is not surprising because they both appear to be > OpenEmbedded environments. > > Thanks, > > Robert Munro > > *From:*Chris Hinkey <chinkey@geontech.com> > *Sent:* Wednesday, July 17, 2019 4:34 PM > *To:* James Kulp <jek@parera.com> > *Cc:* Munro, Robert M. <Robert.Munro@jhuapl.edu>; > discuss@lists.opencpi.org > *Subject:* Re: [Discuss OpenCPI] Issue building OCPI components using > new RCC platform based on N310 SDK > > I think I am running in to a same/similar problem today with a yocto > based toolchain that requires a environmental script be called prior > to using it. > > the way rcc workers are built by calling the compiler executables > directly instead of using the standard variables will likley cause > similar build errors to these when building in both of these instances > right? > > environment script: > > # Check for LD_LIBRARY_PATH being set, which can break SDK and > generally is a bad practice > # http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80 > # http://xahlee.info/UnixResource_dir/_/ldpath.html > # Only disable this check if you are absolutely know what you are doing! > if [ ! -z "$LD_LIBRARY_PATH" ]; then > echo "Your environment is misconfigured, you probably need to > 'unset LD_LIBRARY_PATH'" > echo "but please check why this was set in the first place and > that it's safe to unset." > echo "The SDK will not operate correctly in most cases when > LD_LIBRARY_PATH is set." > echo "For more references see:" > echo " > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80" > echo " http://xahlee.info/UnixResource_dir/_/ldpath.html" > return 1 > fi > export > SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux > export > PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux-musl:$PATH > export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT > export > PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig > export CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux > export > OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux" > export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT" > export OECORE_ACLOCAL_OPTS="-I > /home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal" > export OECORE_BASELIB="lib" > export OECORE_TARGET_ARCH="aarch64" > export OECORE_TARGET_OS="linux" > unset command_not_found_handle > export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT" > export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT" > export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT" > export AS="aarch64-poky-linux-as " > export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT" > export GDB=aarch64-poky-linux-gdb > export STRIP=aarch64-poky-linux-strip > export RANLIB=aarch64-poky-linux-ranlib > export OBJCOPY=aarch64-poky-linux-objcopy > export OBJDUMP=aarch64-poky-linux-objdump > export AR=aarch64-poky-linux-ar > export NM=aarch64-poky-linux-nm > export M4=m4 > export TARGET_PREFIX=aarch64-poky-linux- > export CONFIGURE_FLAGS="--target=aarch64-poky-linux > --host=aarch64-poky-linux --build=x86_64-linux > --with-libtool-sysroot=$SDKTARGETSYSROOT" > export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " > export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " > export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" > export CPPFLAGS="" > export KCFLAGS="--sysroot=$SDKTARGETSYSROOT" > export OECORE_DISTRO_VERSION="2.6.2" > export OECORE_SDK_VERSION="2.6.2" > export ARCH=arm64 > export CROSS_COMPILE=aarch64-poky-linux- > > # Append environment subscripts > if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then > for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do > . $envfile > done > fi > if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then > for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do > . $envfile > done > fi > > On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek@parera.com > <mailto:jek@parera.com>> wrote: > > Robert, > > Ok. Since Ettus SDKs are certainly something we need to deal with, I > looked into this carefully. > I had to make some OpenCPI patches to support cross tools that > required > extra command line and environment info like these do. > Our previous cross-tools (4 or 5, including some altera/arm and other > xilinx sdk ones) did not require this. > I now have a clean build of all the prereqs and the framework itself > using this tool set. > How/where did you get the kernel headers from Ettus? The OpenCPI > kernel > driver is the last software thing to build. > > I'll be sending a proper patch in a few days so it can be applied to > release 1.5 (which will be posted in the next day or so). > Thanks for the info on this so we can support this sort of thing > better > going forward. > > Jim > > On 7/16/19 4:54 PM, Munro, Robert M. wrote: > > Jim, > > > > Attached here. > > > > I believe it was attached with the original message to show how > the environment is being specified to the framework along with > request to know any variables that are necessary or incorrect. > > > > Thanks, > > Robert Munro > > > > -----Original Message----- > > From: James Kulp <jek@parera.com <mailto:jek@parera.com>> > > Sent: Tuesday, July 16, 2019 4:45 PM > > To: Munro, Robert M. <Robert.Munro@jhuapl.edu > <mailto:Robert.Munro@jhuapl.edu>>; discuss@lists.opencpi.org > <mailto:discuss@lists.opencpi.org> > > Subject: Re: [Discuss OpenCPI] Issue building OCPI components > using new RCC platform based on N310 SDK > > > > One more request: can you send what you are using for > ettus_n310_sdk.mk <http://ettus_n310_sdk.mk>? > > Basically I want to discover where we are sensitive to certain > environment settings and should not be. > > Our builds go to some length to make sure everything relevant is > specified in the file, and nothing depends on the environment. > > > > Thanks. > > > > On 7/15/19 12:52 PM, Munro, Robert M. wrote: > >> Jim, > >> > >> It looks like the compilation executable environment variables > are being overridden. In the sourced SDK environment the CC, CXX, > and LD variables are more than the executable but the OCPI > environment does not appear to take in the OcpiCFlags and > OcpiCXXFlags that are defined in ettus_n310_sdk.mk > <http://ettus_n310_sdk.mk>. > >> > >> Attached output from the env and printenv commands. > >> > >> The install-ad9361.sh script was found and followed to generate > the required library for assets project compilation. The script > build/build-opencpi.sh ettus_n310-sdk was run in an attempt to > build the entire framework but it failed when attempting to build > its first application with errors stating that ld is unable to > find crt*.o and multiple libraries that it is attempting to link. > >> > >> Thanks, > >> Robert Munro > >> > >> -----Original Message----- > >> From: James Kulp <jek@parera.com <mailto:jek@parera.com>> > >> Sent: Monday, July 15, 2019 10:46 AM > >> To: Munro, Robert M. <Robert.Munro@jhuapl.edu > <mailto:Robert.Munro@jhuapl.edu>>; > >> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > >> Subject: Re: [Discuss OpenCPI] Issue building OCPI components using > >> new RCC platform based on N310 SDK > >> > >> Yes the compiler flags are the issue - I'm just trying to > figure out where they are coming from. > >> > >> Prerequisite build scripts are in three places: > >> 1. Framework prerequisites in build/prerequisites 2. > Per-project prerequisites in the prerequisites subdirectory of > projects 3. Per-platform prerequisites (like installing a > cross-compiler), in the rcc platform's directory. > >> > >> > >> On 7/15/19 10:34 AM, Munro, Robert M. wrote: > >>> Jim, > >>> > >>> Agreed that the difference between the calls from within > install-prerequisites.sh and direct is the environment being > used. It's likely the important difference being the parameters > passed to gcc and g++ applications shown as the additional > '-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 > --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi' > in the direct call. I can work on posting a more complete > environment listing, but suspect this difference will be important. > >>> > >>> Does the install-prerequisites.sh script override the $CC and > $CXX environment variables which removes the additional flags? I > believed that by specifying the additional flags in the > ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> they would be part of > the environment as they are when compiling projects using 'ocpidev > build project ... -rcc-platform ettus_n310_sdk' . > >>> > >>> The build/autotools components completed a build manually with > some modifications to autotools/gen/configure. The lines where > -Werror=null-dereference and -Werror=maybe-uninitialized are added > to compiler flag lists needed to be commented. I was not sure how > to correctly remove the compilation flags in this case. > >> Any changes to compilation flags are in the .mk file for the > platform, > >> including overriding defaults. > >> > >> But those flags (the "error" ones) should only be used with > framework > >> code which is clean for them. > >> > >> Obviously we are interested in seeing whatever patches you found as > >> required. > >> > >>> Where are the compilation steps required for the ad9361 > library described? That prerequisite is currently preventing the > compilation of the assets project. > >>> > >>> Thanks, > >>> Robert Munro > >>> > >>> -----Original Message----- > >>> From: discuss <discuss-bounces@lists.opencpi.org > <mailto:discuss-bounces@lists.opencpi.org>> On Behalf Of James > >>> Kulp > >>> Sent: Monday, July 15, 2019 8:52 AM > >>> To: discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > >>> Subject: Re: [Discuss OpenCPI] Issue building OCPI components > using > >>> new RCC platform based on N310 SDK > >>> > >>> Hi Robert, > >>> > >>> Thanks for the report. > >>> So the configure commands are the same in both cases, but are > run in different environments. > >>> Perhaps you could dump the environment along with the set -x > >>> > >>> Jim > >>> > >>> > >>> On 7/12/19 5:53 PM, Munro, Robert M. wrote: > >>>> OCPI Development Team, > >>>> > >>>> An Ettus N310 SDK environment is being integrated into the > OCPI build environment to enable building software for the N310 > target. The RCC platform has been set up and the core project > appears to build successfully using 'ocpidev build project > projects/core -rcc -rcc-platform ettus_n310_sdk'. > >>>> > >>>> When attempting to build the assets project the compiler > throws an error when it doesn't find some libraries from the > prerequisites. I have attempted using the command > 'build/install-prerequisites.sh ettus_n310_sdk' to build and > install all required prerequisites, but this fails in the > configure operation of gmp. By navigating to the > prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and > running the prescribed configure, make, make install commands the > build completes without error. To see the difference between the > two commands 'set +x .. set -x' was added around the configure > command in build/prerequisites/gmp/install-gmp.sh . > >>>> > >>>> Failing configure command: > >>>> ../configure --host=arm-oe-linux-gnueabi > >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp > >>>> > --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et > >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic > >>>> > >>>> Failing configure output: > >>>> checking whether > >>>> > /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- > >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking > >>>> compiler > >>>> > /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- > >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g > >>>> -feliminate-unused-debug-types ... no > >>>> configure: error: could not find a working compiler, see > config.log > >>>> for details > >>>> > >>>> Working configure command: > >>>> ../configure --host=arm-oe-linux-gnueabi > >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp > >>>> > --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et > >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic > >>>> > >>>> Working configure output: > >>>> checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm > >>>> -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 > >>>> > --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux > >>>> -g nueabi is gcc... yes checking compiler > arm-oe-linux-gnueabi-gcc > >>>> -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 > >>>> > --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux > >>>> -g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes > >>>> > >>>> Since the install-prerequisites.sh script fails in gmp > library, the liquid, lzma, and gtest libraries must be built and > succeed using a similar manual approach. The assets project is > then able to build several RCC elements until it reaches the > ad9361_config_proxy.so where it is looking for the libad9361.a . > After searching in similar places as the build steps for the other > prerequisites (build/prerequisites/<library>) the appropriate > instructions for manually building the ad9361 library are not able > to be found. Where are the build steps described for this library? > >>>> > >>>> Likewise the build of the build/autotools/ products using > this SDK requires manual configuration and is currently failing to > complete. > >>>> > >>>> Is the use of a non-Xilinx SDK unsupported for the framework > or are there more elements that can be supplied to the framework > to support this use case? A copy of the RCC configuration file is > attached for reference. > >>>> > >>>> Thank you, > >>>> Robert Munro > >>>> -------------- next part -------------- An HTML attachment was > >>>> scrubbed... > >>>> URL: > >>>> > <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach > >>>> me nts/20190712/d87a4d9e/attachment.html> > >>>> -------------- next part -------------- A non-text attachment was > >>>> scrubbed... > >>>> Name: ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> > >>>> Type: application/octet-stream > >>>> Size: 2431 bytes > >>>> Desc: ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> > >>>> URL: > >>>> > <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach > >>>> me nts/20190712/d87a4d9e/attachment.mk <http://attachment.mk>> > >>>> _______________________________________________ > >>>> discuss mailing list > >>>> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > >>>> > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > >>> _______________________________________________ > >>> discuss mailing list > >>> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > >>> > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > > > > _______________________________________________ > discuss mailing list > discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org >

Munro, Robert M.

Thu, Jul 18, 2019 3:48 PM

Jim,

The reality of cross-compilation toolchains is they require a way to supply non-standardized specifics about the target hardware and execution environment. I believed that specifying the same environment information in the rcc-platform.mk file the tools could be properly instructed. It is unfortunate to have to replicate information in multiple formats and locations but realistic when using multiple disparate toolsets. It appears to me that use of bash scripting in general requires awareness of the bash environment when passing commands to subsystems.

Xilinx SDK has the luxury of being built for a relatively small number of variances and as such it is relatively easy to supply a turnkey solution. Xilinx also has a system and project standardization that enables everything to know where things are or should be. The only open-source projects I can think of that aspire to such goals and serve as wide array of targets as OpenEmbedded are Linux and GNURadio and even they can have their challenges.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp jek@parera.com
Sent: Thursday, July 18, 2019 8:07 AM
To: Munro, Robert M. Robert.Munro@jhuapl.edu; Chris Hinkey chinkey@geontech.com
Cc: discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new RCC platform based on N310 SDK

On 7/17/19 6:03 PM, Munro, Robert M. wrote:

Jim,

Thanks for your insight and assistance in using this SDK in the OCPI
framework. I believe the Ettus SDKs and more generally the OE
framework are likely to become commonplace build systems for embedded
architectures due to their flexibility and extendibility.

I agree. Sad but true. Their SDKs are clearly not designed to coexist with any other tools.

Many people expect to do ./configure && make, and ./configure --help suggests adding compiler flags using a CFLAGS argument, but when you use the OE SDK you have to know that CFLAGS is already set in the environment, and you must do something like CFLAGS="$CFLAGS --special-flag".

And people that write Makefiles think that they use CFLAGS to set compilation flags beyond the defaults of the compiler, but OE SDK requires you to remember that it sets environment variables outside of Make and make files.

And people that write Makefiles that create both host binaries and cross binaries can't since the environment variables set by the SDK can trash the host compilation.

Basically their design decisions conflict with our multi-target build environment.

But we can deal with it. It boils down to:

all prerequisite build scripts (mostly ./configure && make) must be aware of the unusual environment behavior
all uses of OE cross-tools must be wrapped in a two line script that sources the environment setup locally

The kernel source tree that is being used in my development
environment was generated using Ettus' N310 docker container and build
system that is described here
https://github.com/EttusResearch/ettus-docker/tree/master/oe-build
using the steps from 'docker run ...' to 'build_imgs_package.sh...' to
generate an image. Upon completion there will be kernel-source and
kernel-build-artifacts directories in build/tmp-glibc/work-shared/<NI kernel version name>/ . There will also be a folder with all the
kernel compilation outputs located in build/tmp-glibc/work/<NI kernel version name>-oe-linux-gnueabi/linux-yocto/<yocto kernel version and git information>/linux-<NI kernel version name>-standard-build/ . I
am not familiar enough with the build system to know how to generate
only these outputs directly.

Right - we essentially use the Redhat/Centos model and expect to install/download/create a "kernel-headers" directory or tarball for the kernel in question.

For grins, the environment delta that the SDK environment setup creates is:

AR=arm-oe-linux-gnueabi-ar
ARCH=arm
AS=arm-oe-linux-gnueabi-as
CC=arm-oe-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon

-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn
ueabi

CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types

CONFIG_SITE=/home/jek/mac/Ettus/sdk/site-config-cortexa9hf-neon-oe-lin
ux-gnueabi

CONFIGURE_FLAGS=--target=arm-oe-linux-gnueabi

--host=arm-oe-linux-gnueabi --build=x86_64-linux
--with-libtool-sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neo
n-oe-linux-gnueabi

CPP=arm-oe-linux-gnueabi-gcc -E -march=armv7-a -marm -mfpu=neon

-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn
ueabi

CPPFLAGS=
CROSS_COMPILE=arm-oe-linux-gnueabi-
CXX=arm-oe-linux-gnueabi-g++ -march=armv7-a -marm -mfpu=neon

-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn
ueabi

CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
GDB=arm-oe-linux-gnueabi-gdb

KCFLAGS=--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-
linux-gnueabi

LD=arm-oe-linux-gnueabi-ld

--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn
ueabi

LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
M4=m4
NM=arm-oe-linux-gnueabi-nm
OBJCOPY=arm-oe-linux-gnueabi-objcopy
OBJDUMP=arm-oe-linux-gnueabi-objdump
OECORE_ACLOCAL_OPTS=-I

/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/share/aclocal

OECORE_DISTRO_VERSION=2018.04

OECORE_NATIVE_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-li
nux

OECORE_SDK_VERSION=nodistro.0

OECORE_TARGET_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon
-oe-linux-gnueabi

PKG_CONFIG_PATH=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-li
nux-gnueabi/usr/lib/pkgconfig:/home/jek/mac/Ettus/sdk/sysroots/cortexa
9hf-neon-oe-linux-gnueabi/usr/share/pkgconfig

PKG_CONFIG_SYSROOT_DIR=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neo
n-oe-linux-gnueabi

RANLIB=arm-oe-linux-gnueabi-ranlib

SDKTARGETSYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-l
inux-gnueabi

STRIP=arm-oe-linux-gnueabi-strip
TARGET_PREFIX=arm-oe-linux-gnueabi-

<
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/hom
e/jek/.local/bin:/home/jek/bin

PATH=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin:/home
/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/sbin:/home/jek/mac/
Ettus/sdk/sysroots/x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/sysr
oots/x86_64-oesdk-linux/sbin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-o
esdk-linux/usr/bin/../x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/s
ysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi:/home/jek/mac/
Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musl:/usr/l
ocal/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.loca
l/bin:/home/jek/bin

Chris,

It looks like your build environment is similar to the Ettus SDK
environment. This is not surprising because they both appear to be
OpenEmbedded environments.

Thanks,

Robert Munro

I think I am running in to a same/similar problem today with a yocto
based toolchain that requires a environmental script be called prior
to using it.

the way rcc workers are built by calling the compiler executables
directly instead of using the standard variables will likley cause
similar build errors to these when building in both of these instances
right?

environment script:

Check for LD_LIBRARY_PATH being set, which can break SDK and

generally is a bad practice #
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN8
0 # http://xahlee.info/UnixResource_dir/_/ldpath.html

Only disable this check if you are absolutely know what you are doing!

if [ ! -z "$LD_LIBRARY_PATH" ]; then
echo "Your environment is misconfigured, you probably need to
'unset LD_LIBRARY_PATH'"
echo "but please check why this was set in the first place and
that it's safe to unset."
echo "The SDK will not operate correctly in most cases when
LD_LIBRARY_PATH is set."
echo "For more references see:"
echo "
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80"
echo " http://xahlee.info/UnixResource_dir/_/ldpath.html"
return 1
fi
export
SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux
export
PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/ho
me/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chin
key/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchai
n/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/
x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey
/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/h
ome/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-po
ky-linux-musl:$PATH export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export
PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/
usr/share/pkgconfig export
CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux
export
OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
export OECORE_ACLOCAL_OPTS="-I
/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export OECORE_BASELIB="lib"
export OECORE_TARGET_ARCH="aarch64"
export OECORE_TARGET_OS="linux"
unset command_not_found_handle
export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT"
export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT"
export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT"
export AS="aarch64-poky-linux-as "
export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT"
export GDB=aarch64-poky-linux-gdb
export STRIP=aarch64-poky-linux-strip
export RANLIB=aarch64-poky-linux-ranlib export
OBJCOPY=aarch64-poky-linux-objcopy
export OBJDUMP=aarch64-poky-linux-objdump
export AR=aarch64-poky-linux-ar
export NM=aarch64-poky-linux-nm
export M4=m4
export TARGET_PREFIX=aarch64-poky-linux- export
CONFIGURE_FLAGS="--target=aarch64-poky-linux
--host=aarch64-poky-linux --build=x86_64-linux
--with-libtool-sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
export CPPFLAGS=""
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
export OECORE_DISTRO_VERSION="2.6.2"
export OECORE_SDK_VERSION="2.6.2"
export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-

Append environment subscripts

On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek@parera.com
mailto:jek@parera.com> wrote:

 Robert,

 Ok. Since Ettus SDKs are certainly something we need to deal with, I
 looked into this carefully.
 I had to make some OpenCPI patches to support cross tools that
 required
 extra command line and environment info like these do.
 Our previous cross-tools (4 or 5, including some altera/arm and other
 xilinx sdk ones) did not require this.
 I now have a clean build of all the prereqs and the framework itself
 using this tool set.
 How/where did you get the kernel headers from Ettus?  The OpenCPI
 kernel
 driver is the last software thing to build.

 I'll be sending a proper patch in a few days so it can be applied to
 release 1.5 (which will be posted in the next day or so).
 Thanks for the info on this so we can support this sort of thing
 better
 going forward.

 Jim

 On 7/16/19 4:54 PM, Munro, Robert M. wrote:

Jim,

Attached here.

I believe it was attached with the original message to show how

 the environment is being specified to the framework along with
 request to know any variables that are necessary or incorrect.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp <jek@parera.com mailto:jek@parera.com>
Sent: Tuesday, July 16, 2019 4:45 PM
To: Munro, Robert M. <Robert.Munro@jhuapl.edu

 <mailto:Robert.Munro@jhuapl.edu>>; discuss@lists.opencpi.org
 <mailto:discuss@lists.opencpi.org>

Subject: Re: [Discuss OpenCPI] Issue building OCPI components

 using new RCC platform based on N310 SDK

One more request: can you send what you are using for

 ettus_n310_sdk.mk <http://ettus_n310_sdk.mk>?

Basically I want to discover where we are sensitive to certain

 environment settings and should not be.

Our builds go to some length to make sure everything relevant is

 specified in the file, and nothing depends on the environment.

Thanks.

On 7/15/19 12:52 PM, Munro, Robert M. wrote:

Jim,

It looks like the compilation executable environment variables

 are being overridden.  In the sourced SDK environment the CC, CXX,
 and LD variables are more than the executable but the OCPI
 environment does not appear to take in the OcpiCFlags and
 OcpiCXXFlags that are defined in ettus_n310_sdk.mk
 <http://ettus_n310_sdk.mk>.

Attached output from the env and printenv commands.

The install-ad9361.sh script was found and followed to generate

 the required library for assets project compilation.  The script
 build/build-opencpi.sh ettus_n310-sdk was run in an attempt to
 build the entire framework but it failed when attempting to build
 its first application with errors stating that ld is unable to
 find crt*.o and multiple libraries that it is attempting to link.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp <jek@parera.com mailto:jek@parera.com>
Sent: Monday, July 15, 2019 10:46 AM
To: Munro, Robert M. <Robert.Munro@jhuapl.edu

 <mailto:Robert.Munro@jhuapl.edu>>;

discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using
new RCC platform based on N310 SDK

Yes the compiler flags are the issue - I'm just trying to

 figure out where they are coming from.

Prerequisite build scripts are in three places:

Framework prerequisites in build/prerequisites 2.

 Per-project prerequisites in the prerequisites subdirectory of
 projects 3. Per-platform prerequisites (like installing a
 cross-compiler), in the rcc platform's directory.

On 7/15/19 10:34 AM, Munro, Robert M. wrote:

Jim,

Agreed that the difference between the calls from within

 install-prerequisites.sh and direct is the environment being
 used.  It's likely the important difference being the parameters
 passed to gcc and g++ applications shown as the additional
 '-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi'
 in the direct call.  I can work on posting a more complete
 environment listing, but suspect this difference will be important.

Does the install-prerequisites.sh script override the $CC and

 $CXX environment variables which removes the additional flags?  I
 believed that by specifying the additional flags in the
 ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> they would be part of
 the environment as they are when compiling projects using 'ocpidev
 build project ... -rcc-platform ettus_n310_sdk' .

The build/autotools components completed a build manually with

 some modifications to autotools/gen/configure.  The lines where
 -Werror=null-dereference and -Werror=maybe-uninitialized are added
 to compiler flag lists needed to be commented. I was not sure how
 to correctly remove the compilation flags in this case.

Any changes to compilation flags are in the .mk file for the

 platform,

including overriding defaults.

But those flags (the "error" ones) should only be used with

 framework

code which is clean for them.

Obviously we are interested in seeing whatever patches you found as
required.

Where are the compilation steps required for the ad9361

 library described?  That prerequisite is currently preventing the
 compilation of the assets project.

Thanks,
Robert Munro

-----Original Message-----
From: discuss <discuss-bounces@lists.opencpi.org

 <mailto:discuss-bounces@lists.opencpi.org>> On Behalf Of James

Kulp
Sent: Monday, July 15, 2019 8:52 AM
To: discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components

 using

new RCC platform based on N310 SDK

Hi Robert,

Thanks for the report.
So the configure commands are the same in both cases, but are

 run in different environments.

Perhaps you could dump the environment along with the set -x

Jim

On 7/12/19 5:53 PM, Munro, Robert M. wrote:

OCPI Development Team,

An Ettus N310 SDK environment is being integrated into the

 OCPI build environment to enable building software for the N310
 target.  The RCC platform has been set up and the core project
 appears to build successfully using 'ocpidev build project
 projects/core -rcc -rcc-platform ettus_n310_sdk'.

When attempting to build the assets project the compiler

 throws an error when it doesn't find some libraries from the
 prerequisites.  I have attempted using the command
 'build/install-prerequisites.sh ettus_n310_sdk' to build and
 install all required prerequisites, but this fails in the
 configure operation of gmp.  By navigating to the
 prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and
 running the prescribed configure, make, make install commands the
 build completes without error.  To see the difference between the
 two commands 'set +x .. set -x' was added around the configure
 command in build/prerequisites/gmp/install-gmp.sh .

Failing configure command:
../configure --host=arm-oe-linux-gnueabi
--prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp

 --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et

tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic

Failing configure output:
checking whether

 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-

li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking
compiler

 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-

li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g
-feliminate-unused-debug-types ... no
configure: error: could not find a working compiler, see

 config.log

for details

Working configure command:
../configure --host=arm-oe-linux-gnueabi
--prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp

 --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et

tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic

Working configure output:
checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm
-mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9

 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux

-g nueabi is gcc... yes checking compiler

 arm-oe-linux-gnueabi-gcc

-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9

 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux

-g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes

Since the install-prerequisites.sh script fails in gmp

 library, the liquid, lzma, and gtest libraries must be built and
 succeed using a similar manual approach.  The assets project is
 then able to build several RCC elements until it reaches the
 ad9361_config_proxy.so where it is looking for the libad9361.a . 
 After searching in similar places as the build steps for the other
 prerequisites (build/prerequisites/<library>) the appropriate
 instructions for manually building the ad9361 library are not able
 to be found.  Where are the build steps described for this library?

Likewise the build of the build/autotools/ products using

 this SDK requires manual configuration and is currently failing to
 complete.

Is the use of a non-Xilinx SDK unsupported for the framework

 or are there more elements that can be supplied to the framework
 to support this use case?  A copy of the RCC configuration file is
 attached for reference.

Thank you,
Robert Munro
-------------- next part -------------- An HTML attachment was
scrubbed...
URL:

 <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach

 <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach

me nts/20190712/d87a4d9e/attachment.mk http://attachment.mk>

discuss mailing list
discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org

 http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

discuss mailing list
discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org

http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

 _______________________________________________
 discuss mailing list
 discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org>

http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

Jim, The reality of cross-compilation toolchains is they require a way to supply non-standardized specifics about the target hardware and execution environment. I believed that specifying the same environment information in the rcc-platform.mk file the tools could be properly instructed. It is unfortunate to have to replicate information in multiple formats and locations but realistic when using multiple disparate toolsets. It appears to me that use of bash scripting in general requires awareness of the bash environment when passing commands to subsystems. Xilinx SDK has the luxury of being built for a relatively small number of variances and as such it is relatively easy to supply a turnkey solution. Xilinx also has a system and project standardization that enables everything to know where things are or should be. The only open-source projects I can think of that aspire to such goals and serve as wide array of targets as OpenEmbedded are Linux and GNURadio and even they can have their challenges. Thanks, Robert Munro -----Original Message----- From: James Kulp <jek@parera.com> Sent: Thursday, July 18, 2019 8:07 AM To: Munro, Robert M. <Robert.Munro@jhuapl.edu>; Chris Hinkey <chinkey@geontech.com> Cc: discuss@lists.opencpi.org Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new RCC platform based on N310 SDK On 7/17/19 6:03 PM, Munro, Robert M. wrote: > > Jim, > > Thanks for your insight and assistance in using this SDK in the OCPI > framework. I believe the Ettus SDKs and more generally the OE > framework are likely to become commonplace build systems for embedded > architectures due to their flexibility and extendibility. > I agree. Sad but true. Their SDKs are clearly not designed to coexist with any other tools. Many people expect to do ./configure && make, and ./configure --help suggests adding compiler flags using a CFLAGS argument, but when you use the OE SDK you have to know that CFLAGS is already set in the environment, and you must do something like CFLAGS="$CFLAGS --special-flag". And people that write Makefiles think that they use CFLAGS to set compilation flags beyond the defaults of the compiler, but OE SDK requires you to remember that it sets environment variables outside of Make and make files. And people that write Makefiles that create both host binaries and cross binaries can't since the environment variables set by the SDK can trash the host compilation. Basically their design decisions conflict with our multi-target build environment. But we can deal with it. It boils down to: - all prerequisite build scripts (mostly ./configure && make) must be aware of the unusual environment behavior - all uses of OE cross-tools must be wrapped in a two line script that sources the environment setup locally > The kernel source tree that is being used in my development > environment was generated using Ettus' N310 docker container and build > system that is described here > https://github.com/EttusResearch/ettus-docker/tree/master/oe-build > using the steps from 'docker run ...' to 'build_imgs_package.sh...' to > generate an image. Upon completion there will be kernel-source and > kernel-build-artifacts directories in build/tmp-glibc/work-shared/<NI > kernel version name>/ . There will also be a folder with all the > kernel compilation outputs located in build/tmp-glibc/work/<NI kernel > version name>-oe-linux-gnueabi/linux-yocto/<yocto kernel version and > git information>/linux-<NI kernel version name>-standard-build/ . I > am not familiar enough with the build system to know how to generate > only these outputs directly. > Right - we essentially use the Redhat/Centos model and expect to install/download/create a "kernel-headers" directory or tarball for the kernel in question. For grins, the environment delta that the SDK environment setup creates is: > > AR=arm-oe-linux-gnueabi-ar > > ARCH=arm > > AS=arm-oe-linux-gnueabi-as > > CC=arm-oe-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon > -mfloat-abi=hard -mcpu=cortex-a9 > --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn > ueabi > > CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types > > > CONFIG_SITE=/home/jek/mac/Ettus/sdk/site-config-cortexa9hf-neon-oe-lin > ux-gnueabi > > CONFIGURE_FLAGS=--target=arm-oe-linux-gnueabi > --host=arm-oe-linux-gnueabi --build=x86_64-linux > --with-libtool-sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neo > n-oe-linux-gnueabi > > CPP=arm-oe-linux-gnueabi-gcc -E -march=armv7-a -marm -mfpu=neon > -mfloat-abi=hard -mcpu=cortex-a9 > --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn > ueabi > > CPPFLAGS= > > CROSS_COMPILE=arm-oe-linux-gnueabi- > > CXX=arm-oe-linux-gnueabi-g++ -march=armv7-a -marm -mfpu=neon > -mfloat-abi=hard -mcpu=cortex-a9 > --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn > ueabi > > CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types > > GDB=arm-oe-linux-gnueabi-gdb > > > KCFLAGS=--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe- > linux-gnueabi > > LD=arm-oe-linux-gnueabi-ld > --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn > ueabi > > LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed > > M4=m4 > > NM=arm-oe-linux-gnueabi-nm > > OBJCOPY=arm-oe-linux-gnueabi-objcopy > > OBJDUMP=arm-oe-linux-gnueabi-objdump > > OECORE_ACLOCAL_OPTS=-I > /home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/share/aclocal > > OECORE_DISTRO_VERSION=2018.04 > > > OECORE_NATIVE_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-li > nux > > OECORE_SDK_VERSION=nodistro.0 > > > OECORE_TARGET_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon > -oe-linux-gnueabi > > > PKG_CONFIG_PATH=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-li > nux-gnueabi/usr/lib/pkgconfig:/home/jek/mac/Ettus/sdk/sysroots/cortexa > 9hf-neon-oe-linux-gnueabi/usr/share/pkgconfig > > > PKG_CONFIG_SYSROOT_DIR=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neo > n-oe-linux-gnueabi > > RANLIB=arm-oe-linux-gnueabi-ranlib > > > SDKTARGETSYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-l > inux-gnueabi > > STRIP=arm-oe-linux-gnueabi-strip > > TARGET_PREFIX=arm-oe-linux-gnueabi- > < > PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/hom > e/jek/.local/bin:/home/jek/bin > --- > > > PATH=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin:/home > /jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/sbin:/home/jek/mac/ > Ettus/sdk/sysroots/x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/sysr > oots/x86_64-oesdk-linux/sbin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-o > esdk-linux/usr/bin/../x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/s > ysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi:/home/jek/mac/ > Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musl:/usr/l > ocal/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.loca > l/bin:/home/jek/bin > Chris, > > It looks like your build environment is similar to the Ettus SDK > environment. This is not surprising because they both appear to be > OpenEmbedded environments. > > Thanks, > > Robert Munro > > *From:*Chris Hinkey <chinkey@geontech.com> > *Sent:* Wednesday, July 17, 2019 4:34 PM > *To:* James Kulp <jek@parera.com> > *Cc:* Munro, Robert M. <Robert.Munro@jhuapl.edu>; > discuss@lists.opencpi.org > *Subject:* Re: [Discuss OpenCPI] Issue building OCPI components using > new RCC platform based on N310 SDK > > I think I am running in to a same/similar problem today with a yocto > based toolchain that requires a environmental script be called prior > to using it. > > the way rcc workers are built by calling the compiler executables > directly instead of using the standard variables will likley cause > similar build errors to these when building in both of these instances > right? > > environment script: > > # Check for LD_LIBRARY_PATH being set, which can break SDK and > generally is a bad practice # > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN8 > 0 # http://xahlee.info/UnixResource_dir/_/ldpath.html > # Only disable this check if you are absolutely know what you are doing! > if [ ! -z "$LD_LIBRARY_PATH" ]; then > echo "Your environment is misconfigured, you probably need to > 'unset LD_LIBRARY_PATH'" > echo "but please check why this was set in the first place and > that it's safe to unset." > echo "The SDK will not operate correctly in most cases when > LD_LIBRARY_PATH is set." > echo "For more references see:" > echo " > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80" > echo " http://xahlee.info/UnixResource_dir/_/ldpath.html" > return 1 > fi > export > SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux > export > PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/ho > me/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chin > key/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchai > n/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/ > x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey > /toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/h > ome/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-po > ky-linux-musl:$PATH export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT > export > PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/ > usr/share/pkgconfig export > CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux > export > OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux" > export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT" > export OECORE_ACLOCAL_OPTS="-I > /home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal" > export OECORE_BASELIB="lib" > export OECORE_TARGET_ARCH="aarch64" > export OECORE_TARGET_OS="linux" > unset command_not_found_handle > export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT" > export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT" > export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT" > export AS="aarch64-poky-linux-as " > export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT" > export GDB=aarch64-poky-linux-gdb > export STRIP=aarch64-poky-linux-strip > export RANLIB=aarch64-poky-linux-ranlib export > OBJCOPY=aarch64-poky-linux-objcopy > export OBJDUMP=aarch64-poky-linux-objdump > export AR=aarch64-poky-linux-ar > export NM=aarch64-poky-linux-nm > export M4=m4 > export TARGET_PREFIX=aarch64-poky-linux- export > CONFIGURE_FLAGS="--target=aarch64-poky-linux > --host=aarch64-poky-linux --build=x86_64-linux > --with-libtool-sysroot=$SDKTARGETSYSROOT" > export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " > export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " > export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" > export CPPFLAGS="" > export KCFLAGS="--sysroot=$SDKTARGETSYSROOT" > export OECORE_DISTRO_VERSION="2.6.2" > export OECORE_SDK_VERSION="2.6.2" > export ARCH=arm64 > export CROSS_COMPILE=aarch64-poky-linux- > > # Append environment subscripts > if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then > for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do > . $envfile > done > fi > if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then > for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do > . $envfile > done > fi > > On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek@parera.com > <mailto:jek@parera.com>> wrote: > > Robert, > > Ok. Since Ettus SDKs are certainly something we need to deal with, I > looked into this carefully. > I had to make some OpenCPI patches to support cross tools that > required > extra command line and environment info like these do. > Our previous cross-tools (4 or 5, including some altera/arm and other > xilinx sdk ones) did not require this. > I now have a clean build of all the prereqs and the framework itself > using this tool set. > How/where did you get the kernel headers from Ettus? The OpenCPI > kernel > driver is the last software thing to build. > > I'll be sending a proper patch in a few days so it can be applied to > release 1.5 (which will be posted in the next day or so). > Thanks for the info on this so we can support this sort of thing > better > going forward. > > Jim > > On 7/16/19 4:54 PM, Munro, Robert M. wrote: > > Jim, > > > > Attached here. > > > > I believe it was attached with the original message to show how > the environment is being specified to the framework along with > request to know any variables that are necessary or incorrect. > > > > Thanks, > > Robert Munro > > > > -----Original Message----- > > From: James Kulp <jek@parera.com <mailto:jek@parera.com>> > > Sent: Tuesday, July 16, 2019 4:45 PM > > To: Munro, Robert M. <Robert.Munro@jhuapl.edu > <mailto:Robert.Munro@jhuapl.edu>>; discuss@lists.opencpi.org > <mailto:discuss@lists.opencpi.org> > > Subject: Re: [Discuss OpenCPI] Issue building OCPI components > using new RCC platform based on N310 SDK > > > > One more request: can you send what you are using for > ettus_n310_sdk.mk <http://ettus_n310_sdk.mk>? > > Basically I want to discover where we are sensitive to certain > environment settings and should not be. > > Our builds go to some length to make sure everything relevant is > specified in the file, and nothing depends on the environment. > > > > Thanks. > > > > On 7/15/19 12:52 PM, Munro, Robert M. wrote: > >> Jim, > >> > >> It looks like the compilation executable environment variables > are being overridden. In the sourced SDK environment the CC, CXX, > and LD variables are more than the executable but the OCPI > environment does not appear to take in the OcpiCFlags and > OcpiCXXFlags that are defined in ettus_n310_sdk.mk > <http://ettus_n310_sdk.mk>. > >> > >> Attached output from the env and printenv commands. > >> > >> The install-ad9361.sh script was found and followed to generate > the required library for assets project compilation. The script > build/build-opencpi.sh ettus_n310-sdk was run in an attempt to > build the entire framework but it failed when attempting to build > its first application with errors stating that ld is unable to > find crt*.o and multiple libraries that it is attempting to link. > >> > >> Thanks, > >> Robert Munro > >> > >> -----Original Message----- > >> From: James Kulp <jek@parera.com <mailto:jek@parera.com>> > >> Sent: Monday, July 15, 2019 10:46 AM > >> To: Munro, Robert M. <Robert.Munro@jhuapl.edu > <mailto:Robert.Munro@jhuapl.edu>>; > >> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > >> Subject: Re: [Discuss OpenCPI] Issue building OCPI components using > >> new RCC platform based on N310 SDK > >> > >> Yes the compiler flags are the issue - I'm just trying to > figure out where they are coming from. > >> > >> Prerequisite build scripts are in three places: > >> 1. Framework prerequisites in build/prerequisites 2. > Per-project prerequisites in the prerequisites subdirectory of > projects 3. Per-platform prerequisites (like installing a > cross-compiler), in the rcc platform's directory. > >> > >> > >> On 7/15/19 10:34 AM, Munro, Robert M. wrote: > >>> Jim, > >>> > >>> Agreed that the difference between the calls from within > install-prerequisites.sh and direct is the environment being > used. It's likely the important difference being the parameters > passed to gcc and g++ applications shown as the additional > '-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 > --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi' > in the direct call. I can work on posting a more complete > environment listing, but suspect this difference will be important. > >>> > >>> Does the install-prerequisites.sh script override the $CC and > $CXX environment variables which removes the additional flags? I > believed that by specifying the additional flags in the > ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> they would be part of > the environment as they are when compiling projects using 'ocpidev > build project ... -rcc-platform ettus_n310_sdk' . > >>> > >>> The build/autotools components completed a build manually with > some modifications to autotools/gen/configure. The lines where > -Werror=null-dereference and -Werror=maybe-uninitialized are added > to compiler flag lists needed to be commented. I was not sure how > to correctly remove the compilation flags in this case. > >> Any changes to compilation flags are in the .mk file for the > platform, > >> including overriding defaults. > >> > >> But those flags (the "error" ones) should only be used with > framework > >> code which is clean for them. > >> > >> Obviously we are interested in seeing whatever patches you found as > >> required. > >> > >>> Where are the compilation steps required for the ad9361 > library described? That prerequisite is currently preventing the > compilation of the assets project. > >>> > >>> Thanks, > >>> Robert Munro > >>> > >>> -----Original Message----- > >>> From: discuss <discuss-bounces@lists.opencpi.org > <mailto:discuss-bounces@lists.opencpi.org>> On Behalf Of James > >>> Kulp > >>> Sent: Monday, July 15, 2019 8:52 AM > >>> To: discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > >>> Subject: Re: [Discuss OpenCPI] Issue building OCPI components > using > >>> new RCC platform based on N310 SDK > >>> > >>> Hi Robert, > >>> > >>> Thanks for the report. > >>> So the configure commands are the same in both cases, but are > run in different environments. > >>> Perhaps you could dump the environment along with the set -x > >>> > >>> Jim > >>> > >>> > >>> On 7/12/19 5:53 PM, Munro, Robert M. wrote: > >>>> OCPI Development Team, > >>>> > >>>> An Ettus N310 SDK environment is being integrated into the > OCPI build environment to enable building software for the N310 > target. The RCC platform has been set up and the core project > appears to build successfully using 'ocpidev build project > projects/core -rcc -rcc-platform ettus_n310_sdk'. > >>>> > >>>> When attempting to build the assets project the compiler > throws an error when it doesn't find some libraries from the > prerequisites. I have attempted using the command > 'build/install-prerequisites.sh ettus_n310_sdk' to build and > install all required prerequisites, but this fails in the > configure operation of gmp. By navigating to the > prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and > running the prescribed configure, make, make install commands the > build completes without error. To see the difference between the > two commands 'set +x .. set -x' was added around the configure > command in build/prerequisites/gmp/install-gmp.sh . > >>>> > >>>> Failing configure command: > >>>> ../configure --host=arm-oe-linux-gnueabi > >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp > >>>> > --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et > >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic > >>>> > >>>> Failing configure output: > >>>> checking whether > >>>> > /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- > >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking > >>>> compiler > >>>> > /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- > >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g > >>>> -feliminate-unused-debug-types ... no > >>>> configure: error: could not find a working compiler, see > config.log > >>>> for details > >>>> > >>>> Working configure command: > >>>> ../configure --host=arm-oe-linux-gnueabi > >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp > >>>> > --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et > >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic > >>>> > >>>> Working configure output: > >>>> checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm > >>>> -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 > >>>> > --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux > >>>> -g nueabi is gcc... yes checking compiler > arm-oe-linux-gnueabi-gcc > >>>> -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 > >>>> > --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux > >>>> -g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes > >>>> > >>>> Since the install-prerequisites.sh script fails in gmp > library, the liquid, lzma, and gtest libraries must be built and > succeed using a similar manual approach. The assets project is > then able to build several RCC elements until it reaches the > ad9361_config_proxy.so where it is looking for the libad9361.a . > After searching in similar places as the build steps for the other > prerequisites (build/prerequisites/<library>) the appropriate > instructions for manually building the ad9361 library are not able > to be found. Where are the build steps described for this library? > >>>> > >>>> Likewise the build of the build/autotools/ products using > this SDK requires manual configuration and is currently failing to > complete. > >>>> > >>>> Is the use of a non-Xilinx SDK unsupported for the framework > or are there more elements that can be supplied to the framework > to support this use case? A copy of the RCC configuration file is > attached for reference. > >>>> > >>>> Thank you, > >>>> Robert Munro > >>>> -------------- next part -------------- An HTML attachment was > >>>> scrubbed... > >>>> URL: > >>>> > <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach > >>>> me nts/20190712/d87a4d9e/attachment.html> > >>>> -------------- next part -------------- A non-text attachment was > >>>> scrubbed... > >>>> Name: ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> > >>>> Type: application/octet-stream > >>>> Size: 2431 bytes > >>>> Desc: ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> > >>>> URL: > >>>> > <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach > >>>> me nts/20190712/d87a4d9e/attachment.mk <http://attachment.mk>> > >>>> _______________________________________________ > >>>> discuss mailing list > >>>> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > >>>> > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > >>> _______________________________________________ > >>> discuss mailing list > >>> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > >>> > > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org > > > > _______________________________________________ > discuss mailing list > discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> > > http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org >

James Kulp

Fri, Jul 19, 2019 12:15 PM

While it was easy enough to get your Ettus/OE SDK to builid all prereqs
and OpenCPI, the required patches are not as clean as they need to be
and I did no execution of course.

I'll send you a patch file for the preliminary changes I made, but I
intend to create a cleaner solution for such SDKs in general "soon" as a
patch to 1.5.

Jim

On 7/18/19 11:48 AM, Munro, Robert M. wrote:

Jim,

Thanks,
Robert Munro

On 7/17/19 6:03 PM, Munro, Robert M. wrote:

Jim,

Thanks for your insight and assistance in using this SDK in the OCPI
framework. I believe the Ettus SDKs and more generally the OE
framework are likely to become commonplace build systems for embedded
architectures due to their flexibility and extendibility.

I agree. Sad but true. Their SDKs are clearly not designed to coexist with any other tools.

Many people expect to do ./configure && make, and ./configure --help suggests adding compiler flags using a CFLAGS argument, but when you use the OE SDK you have to know that CFLAGS is already set in the environment, and you must do something like CFLAGS="$CFLAGS --special-flag".

And people that write Makefiles think that they use CFLAGS to set compilation flags beyond the defaults of the compiler, but OE SDK requires you to remember that it sets environment variables outside of Make and make files.

And people that write Makefiles that create both host binaries and cross binaries can't since the environment variables set by the SDK can trash the host compilation.

Basically their design decisions conflict with our multi-target build environment.

But we can deal with it. It boils down to:

all prerequisite build scripts (mostly ./configure && make) must be aware of the unusual environment behavior
all uses of OE cross-tools must be wrapped in a two line script that sources the environment setup locally

The kernel source tree that is being used in my development
environment was generated using Ettus' N310 docker container and build
system that is described here
https://github.com/EttusResearch/ettus-docker/tree/master/oe-build
using the steps from 'docker run ...' to 'build_imgs_package.sh...' to
generate an image. Upon completion there will be kernel-source and
kernel-build-artifacts directories in build/tmp-glibc/work-shared/<NI kernel version name>/ . There will also be a folder with all the
kernel compilation outputs located in build/tmp-glibc/work/<NI kernel version name>-oe-linux-gnueabi/linux-yocto/<yocto kernel version and git information>/linux-<NI kernel version name>-standard-build/ . I
am not familiar enough with the build system to know how to generate
only these outputs directly.

Right - we essentially use the Redhat/Centos model and expect to install/download/create a "kernel-headers" directory or tarball for the kernel in question.

For grins, the environment delta that the SDK environment setup creates is:

AR=arm-oe-linux-gnueabi-ar
ARCH=arm
AS=arm-oe-linux-gnueabi-as
CC=arm-oe-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon

-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn
ueabi

CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types

CONFIG_SITE=/home/jek/mac/Ettus/sdk/site-config-cortexa9hf-neon-oe-lin
ux-gnueabi

CONFIGURE_FLAGS=--target=arm-oe-linux-gnueabi

--host=arm-oe-linux-gnueabi --build=x86_64-linux
--with-libtool-sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neo
n-oe-linux-gnueabi

CPP=arm-oe-linux-gnueabi-gcc -E -march=armv7-a -marm -mfpu=neon

-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn
ueabi

CPPFLAGS=
CROSS_COMPILE=arm-oe-linux-gnueabi-
CXX=arm-oe-linux-gnueabi-g++ -march=armv7-a -marm -mfpu=neon

-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn
ueabi

CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
GDB=arm-oe-linux-gnueabi-gdb

KCFLAGS=--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-
linux-gnueabi

LD=arm-oe-linux-gnueabi-ld

--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn
ueabi

LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
M4=m4
NM=arm-oe-linux-gnueabi-nm
OBJCOPY=arm-oe-linux-gnueabi-objcopy
OBJDUMP=arm-oe-linux-gnueabi-objdump
OECORE_ACLOCAL_OPTS=-I

/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/share/aclocal

OECORE_DISTRO_VERSION=2018.04

OECORE_NATIVE_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-li
nux

OECORE_SDK_VERSION=nodistro.0

OECORE_TARGET_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon
-oe-linux-gnueabi
PKG_CONFIG_PATH=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-li
nux-gnueabi/usr/lib/pkgconfig:/home/jek/mac/Ettus/sdk/sysroots/cortexa
9hf-neon-oe-linux-gnueabi/usr/share/pkgconfig
PKG_CONFIG_SYSROOT_DIR=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neo
n-oe-linux-gnueabi

RANLIB=arm-oe-linux-gnueabi-ranlib

SDKTARGETSYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-l
inux-gnueabi

STRIP=arm-oe-linux-gnueabi-strip
TARGET_PREFIX=arm-oe-linux-gnueabi-

<
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/hom
e/jek/.local/bin:/home/jek/bin

PATH=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin:/home
/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/sbin:/home/jek/mac/
Ettus/sdk/sysroots/x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/sysr
oots/x86_64-oesdk-linux/sbin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-o
esdk-linux/usr/bin/../x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/s
ysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi:/home/jek/mac/
Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musl:/usr/l
ocal/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.loca
l/bin:/home/jek/bin
Chris,

It looks like your build environment is similar to the Ettus SDK
environment. This is not surprising because they both appear to be
OpenEmbedded environments.

Thanks,

Robert Munro

I think I am running in to a same/similar problem today with a yocto
based toolchain that requires a environmental script be called prior
to using it.

the way rcc workers are built by calling the compiler executables
directly instead of using the standard variables will likley cause
similar build errors to these when building in both of these instances
right?

environment script:

Check for LD_LIBRARY_PATH being set, which can break SDK and

generally is a bad practice #
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN8
0 # http://xahlee.info/UnixResource_dir/_/ldpath.html

Only disable this check if you are absolutely know what you are doing!

if [ ! -z "$LD_LIBRARY_PATH" ]; then
echo "Your environment is misconfigured, you probably need to
'unset LD_LIBRARY_PATH'"
echo "but please check why this was set in the first place and
that it's safe to unset."
echo "The SDK will not operate correctly in most cases when
LD_LIBRARY_PATH is set."
echo "For more references see:"
echo "
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80"
echo " http://xahlee.info/UnixResource_dir/_/ldpath.html"
return 1
fi
export
SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux
export
PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/ho
me/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chin
key/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchai
n/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/
x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey
/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/h
ome/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-po
ky-linux-musl:$PATH export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export
PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/
usr/share/pkgconfig export
CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux
export
OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
export OECORE_ACLOCAL_OPTS="-I
/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export OECORE_BASELIB="lib"
export OECORE_TARGET_ARCH="aarch64"
export OECORE_TARGET_OS="linux"
unset command_not_found_handle
export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT"
export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT"
export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT"
export AS="aarch64-poky-linux-as "
export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT"
export GDB=aarch64-poky-linux-gdb
export STRIP=aarch64-poky-linux-strip
export RANLIB=aarch64-poky-linux-ranlib export
OBJCOPY=aarch64-poky-linux-objcopy
export OBJDUMP=aarch64-poky-linux-objdump
export AR=aarch64-poky-linux-ar
export NM=aarch64-poky-linux-nm
export M4=m4
export TARGET_PREFIX=aarch64-poky-linux- export
CONFIGURE_FLAGS="--target=aarch64-poky-linux
--host=aarch64-poky-linux --build=x86_64-linux
--with-libtool-sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
export CPPFLAGS=""
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
export OECORE_DISTRO_VERSION="2.6.2"
export OECORE_SDK_VERSION="2.6.2"
export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-

Append environment subscripts

On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek@parera.com
mailto:jek@parera.com> wrote:

  Robert,

  Ok. Since Ettus SDKs are certainly something we need to deal with, I
  looked into this carefully.
  I had to make some OpenCPI patches to support cross tools that
  required
  extra command line and environment info like these do.
  Our previous cross-tools (4 or 5, including some altera/arm and other
  xilinx sdk ones) did not require this.
  I now have a clean build of all the prereqs and the framework itself
  using this tool set.
  How/where did you get the kernel headers from Ettus?  The OpenCPI
  kernel
  driver is the last software thing to build.

  I'll be sending a proper patch in a few days so it can be applied to
  release 1.5 (which will be posted in the next day or so).
  Thanks for the info on this so we can support this sort of thing
  better
  going forward.

  Jim

  On 7/16/19 4:54 PM, Munro, Robert M. wrote:

Jim,

Attached here.

I believe it was attached with the original message to show how

  the environment is being specified to the framework along with
  request to know any variables that are necessary or incorrect.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp <jek@parera.com mailto:jek@parera.com>
Sent: Tuesday, July 16, 2019 4:45 PM
To: Munro, Robert M. <Robert.Munro@jhuapl.edu

  <mailto:Robert.Munro@jhuapl.edu>>; discuss@lists.opencpi.org
  <mailto:discuss@lists.opencpi.org>

Subject: Re: [Discuss OpenCPI] Issue building OCPI components

  using new RCC platform based on N310 SDK

One more request: can you send what you are using for

  ettus_n310_sdk.mk <http://ettus_n310_sdk.mk>?

Basically I want to discover where we are sensitive to certain

  environment settings and should not be.

Our builds go to some length to make sure everything relevant is

  specified in the file, and nothing depends on the environment.

Thanks.

On 7/15/19 12:52 PM, Munro, Robert M. wrote:

Jim,

It looks like the compilation executable environment variables

  are being overridden.  In the sourced SDK environment the CC, CXX,
  and LD variables are more than the executable but the OCPI
  environment does not appear to take in the OcpiCFlags and
  OcpiCXXFlags that are defined in ettus_n310_sdk.mk
  <http://ettus_n310_sdk.mk>.

Attached output from the env and printenv commands.

The install-ad9361.sh script was found and followed to generate

  the required library for assets project compilation.  The script
  build/build-opencpi.sh ettus_n310-sdk was run in an attempt to
  build the entire framework but it failed when attempting to build
  its first application with errors stating that ld is unable to
  find crt*.o and multiple libraries that it is attempting to link.

Thanks,
Robert Munro

-----Original Message-----
From: James Kulp <jek@parera.com mailto:jek@parera.com>
Sent: Monday, July 15, 2019 10:46 AM
To: Munro, Robert M. <Robert.Munro@jhuapl.edu

  <mailto:Robert.Munro@jhuapl.edu>>;

discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components using
new RCC platform based on N310 SDK

Yes the compiler flags are the issue - I'm just trying to

  figure out where they are coming from.

Prerequisite build scripts are in three places:

Framework prerequisites in build/prerequisites 2.

  Per-project prerequisites in the prerequisites subdirectory of
  projects 3. Per-platform prerequisites (like installing a
  cross-compiler), in the rcc platform's directory.

On 7/15/19 10:34 AM, Munro, Robert M. wrote:

Jim,

Agreed that the difference between the calls from within

  install-prerequisites.sh and direct is the environment being
  used.  It's likely the important difference being the parameters
  passed to gcc and g++ applications shown as the additional
  '-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
  --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi'
  in the direct call.  I can work on posting a more complete
  environment listing, but suspect this difference will be important.

Does the install-prerequisites.sh script override the $CC and

  $CXX environment variables which removes the additional flags?  I
  believed that by specifying the additional flags in the
  ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> they would be part of
  the environment as they are when compiling projects using 'ocpidev
  build project ... -rcc-platform ettus_n310_sdk' .

The build/autotools components completed a build manually with

  some modifications to autotools/gen/configure.  The lines where
  -Werror=null-dereference and -Werror=maybe-uninitialized are added
  to compiler flag lists needed to be commented. I was not sure how
  to correctly remove the compilation flags in this case.

Any changes to compilation flags are in the .mk file for the

  platform,

including overriding defaults.

But those flags (the "error" ones) should only be used with

  framework

code which is clean for them.

Obviously we are interested in seeing whatever patches you found as
required.

Where are the compilation steps required for the ad9361

  library described?  That prerequisite is currently preventing the
  compilation of the assets project.

Thanks,
Robert Munro

-----Original Message-----
From: discuss <discuss-bounces@lists.opencpi.org

  <mailto:discuss-bounces@lists.opencpi.org>> On Behalf Of James

Kulp
Sent: Monday, July 15, 2019 8:52 AM
To: discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Issue building OCPI components

  using

new RCC platform based on N310 SDK

Hi Robert,

Thanks for the report.
So the configure commands are the same in both cases, but are

  run in different environments.

Perhaps you could dump the environment along with the set -x

Jim

On 7/12/19 5:53 PM, Munro, Robert M. wrote:

OCPI Development Team,

An Ettus N310 SDK environment is being integrated into the

  OCPI build environment to enable building software for the N310
  target.  The RCC platform has been set up and the core project
  appears to build successfully using 'ocpidev build project
  projects/core -rcc -rcc-platform ettus_n310_sdk'.

When attempting to build the assets project the compiler

  throws an error when it doesn't find some libraries from the
  prerequisites.  I have attempted using the command
  'build/install-prerequisites.sh ettus_n310_sdk' to build and
  install all required prerequisites, but this fails in the
  configure operation of gmp.  By navigating to the
  prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and
  running the prescribed configure, make, make install commands the
  build completes without error.  To see the difference between the
  two commands 'set +x .. set -x' was added around the configure
  command in build/prerequisites/gmp/install-gmp.sh .

Failing configure command:
../configure --host=arm-oe-linux-gnueabi
--prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp

  --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et

tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic

Failing configure output:
checking whether

  /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-

li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking
compiler

  /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-

li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g
-feliminate-unused-debug-types ... no
configure: error: could not find a working compiler, see

  config.log

for details

Working configure command:
../configure --host=arm-oe-linux-gnueabi
--prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp

  --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et

tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic

Working configure output:
checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm
-mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9

  --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux

-g nueabi is gcc... yes checking compiler

  arm-oe-linux-gnueabi-gcc

-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9

  --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux

-g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes

Since the install-prerequisites.sh script fails in gmp

  library, the liquid, lzma, and gtest libraries must be built and
  succeed using a similar manual approach.  The assets project is
  then able to build several RCC elements until it reaches the
  ad9361_config_proxy.so where it is looking for the libad9361.a .
  After searching in similar places as the build steps for the other
  prerequisites (build/prerequisites/<library>) the appropriate
  instructions for manually building the ad9361 library are not able
  to be found.  Where are the build steps described for this library?

Likewise the build of the build/autotools/ products using

  this SDK requires manual configuration and is currently failing to
  complete.

Is the use of a non-Xilinx SDK unsupported for the framework

  or are there more elements that can be supplied to the framework
  to support this use case?  A copy of the RCC configuration file is
  attached for reference.

Thank you,
Robert Munro
-------------- next part -------------- An HTML attachment was
scrubbed...
URL:

  <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach

  <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach

me nts/20190712/d87a4d9e/attachment.mk http://attachment.mk>

discuss mailing list
discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org

  http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

discuss mailing list
discuss@lists.opencpi.org mailto:discuss@lists.opencpi.org

http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

  _______________________________________________
  discuss mailing list
  discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org>

http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org

We definitely need to support OpenEmbedded style SDKs since they are becoming more common. I just wish they didn't force everyone to change how they use autotools and make, and didn't rely heavily on a plethora of environment variables that can easily cause obscure support problems. While it was easy enough to get your Ettus/OE SDK to builid all prereqs and OpenCPI, the required patches are not as clean as they need to be and I did no execution of course. I'll send you a patch file for the preliminary changes I made, but I intend to create a cleaner solution for such SDKs in general "soon" as a patch to 1.5. Jim On 7/18/19 11:48 AM, Munro, Robert M. wrote: > Jim, > > The reality of cross-compilation toolchains is they require a way to supply non-standardized specifics about the target hardware and execution environment. I believed that specifying the same environment information in the rcc-platform.mk file the tools could be properly instructed. It is unfortunate to have to replicate information in multiple formats and locations but realistic when using multiple disparate toolsets. It appears to me that use of bash scripting in general requires awareness of the bash environment when passing commands to subsystems. > > Xilinx SDK has the luxury of being built for a relatively small number of variances and as such it is relatively easy to supply a turnkey solution. Xilinx also has a system and project standardization that enables everything to know where things are or should be. The only open-source projects I can think of that aspire to such goals and serve as wide array of targets as OpenEmbedded are Linux and GNURadio and even they can have their challenges. > > Thanks, > Robert Munro > > -----Original Message----- > From: James Kulp <jek@parera.com> > Sent: Thursday, July 18, 2019 8:07 AM > To: Munro, Robert M. <Robert.Munro@jhuapl.edu>; Chris Hinkey <chinkey@geontech.com> > Cc: discuss@lists.opencpi.org > Subject: Re: [Discuss OpenCPI] Issue building OCPI components using new RCC platform based on N310 SDK > > On 7/17/19 6:03 PM, Munro, Robert M. wrote: >> Jim, >> >> Thanks for your insight and assistance in using this SDK in the OCPI >> framework. I believe the Ettus SDKs and more generally the OE >> framework are likely to become commonplace build systems for embedded >> architectures due to their flexibility and extendibility. >> > I agree. Sad but true. Their SDKs are clearly not designed to coexist with any other tools. > > Many people expect to do ./configure && make, and ./configure --help suggests adding compiler flags using a CFLAGS argument, but when you use the OE SDK you have to know that CFLAGS is already set in the environment, and you must do something like CFLAGS="$CFLAGS --special-flag". > > And people that write Makefiles think that they use CFLAGS to set compilation flags beyond the defaults of the compiler, but OE SDK requires you to remember that it sets environment variables outside of Make and make files. > > And people that write Makefiles that create both host binaries and cross binaries can't since the environment variables set by the SDK can trash the host compilation. > > Basically their design decisions conflict with our multi-target build environment. > > But we can deal with it. It boils down to: > > - all prerequisite build scripts (mostly ./configure && make) must be aware of the unusual environment behavior > > - all uses of OE cross-tools must be wrapped in a two line script that sources the environment setup locally > >> The kernel source tree that is being used in my development >> environment was generated using Ettus' N310 docker container and build >> system that is described here >> https://github.com/EttusResearch/ettus-docker/tree/master/oe-build >> using the steps from 'docker run ...' to 'build_imgs_package.sh...' to >> generate an image. Upon completion there will be kernel-source and >> kernel-build-artifacts directories in build/tmp-glibc/work-shared/<NI >> kernel version name>/ . There will also be a folder with all the >> kernel compilation outputs located in build/tmp-glibc/work/<NI kernel >> version name>-oe-linux-gnueabi/linux-yocto/<yocto kernel version and >> git information>/linux-<NI kernel version name>-standard-build/ . I >> am not familiar enough with the build system to know how to generate >> only these outputs directly. >> > Right - we essentially use the Redhat/Centos model and expect to install/download/create a "kernel-headers" directory or tarball for the kernel in question. > > For grins, the environment delta that the SDK environment setup creates is: > >>> AR=arm-oe-linux-gnueabi-ar >>> ARCH=arm >>> AS=arm-oe-linux-gnueabi-as >>> CC=arm-oe-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon >> -mfloat-abi=hard -mcpu=cortex-a9 >> --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn >> ueabi >>> CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types >>> >> CONFIG_SITE=/home/jek/mac/Ettus/sdk/site-config-cortexa9hf-neon-oe-lin >> ux-gnueabi >>> CONFIGURE_FLAGS=--target=arm-oe-linux-gnueabi >> --host=arm-oe-linux-gnueabi --build=x86_64-linux >> --with-libtool-sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neo >> n-oe-linux-gnueabi >>> CPP=arm-oe-linux-gnueabi-gcc -E -march=armv7-a -marm -mfpu=neon >> -mfloat-abi=hard -mcpu=cortex-a9 >> --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn >> ueabi >>> CPPFLAGS= >>> CROSS_COMPILE=arm-oe-linux-gnueabi- >>> CXX=arm-oe-linux-gnueabi-g++ -march=armv7-a -marm -mfpu=neon >> -mfloat-abi=hard -mcpu=cortex-a9 >> --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn >> ueabi >>> CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types >>> GDB=arm-oe-linux-gnueabi-gdb >>> >> KCFLAGS=--sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe- >> linux-gnueabi >>> LD=arm-oe-linux-gnueabi-ld >> --sysroot=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-linux-gn >> ueabi >>> LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed >>> M4=m4 >>> NM=arm-oe-linux-gnueabi-nm >>> OBJCOPY=arm-oe-linux-gnueabi-objcopy >>> OBJDUMP=arm-oe-linux-gnueabi-objdump >>> OECORE_ACLOCAL_OPTS=-I >> /home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/share/aclocal >>> OECORE_DISTRO_VERSION=2018.04 >>> >> OECORE_NATIVE_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-li >> nux >>> OECORE_SDK_VERSION=nodistro.0 >>> >> OECORE_TARGET_SYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon >> -oe-linux-gnueabi >> PKG_CONFIG_PATH=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-li >> nux-gnueabi/usr/lib/pkgconfig:/home/jek/mac/Ettus/sdk/sysroots/cortexa >> 9hf-neon-oe-linux-gnueabi/usr/share/pkgconfig >> PKG_CONFIG_SYSROOT_DIR=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neo >> n-oe-linux-gnueabi >>> RANLIB=arm-oe-linux-gnueabi-ranlib >>> >> SDKTARGETSYSROOT=/home/jek/mac/Ettus/sdk/sysroots/cortexa9hf-neon-oe-l >> inux-gnueabi >>> STRIP=arm-oe-linux-gnueabi-strip >>> TARGET_PREFIX=arm-oe-linux-gnueabi- >> < >> PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/hom >> e/jek/.local/bin:/home/jek/bin >> --- >> PATH=/home/jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin:/home >> /jek/mac/Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/sbin:/home/jek/mac/ >> Ettus/sdk/sysroots/x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/sysr >> oots/x86_64-oesdk-linux/sbin:/home/jek/mac/Ettus/sdk/sysroots/x86_64-o >> esdk-linux/usr/bin/../x86_64-oesdk-linux/bin:/home/jek/mac/Ettus/sdk/s >> ysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi:/home/jek/mac/ >> Ettus/sdk/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musl:/usr/l >> ocal/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.loca >> l/bin:/home/jek/bin >> Chris, >> >> It looks like your build environment is similar to the Ettus SDK >> environment. This is not surprising because they both appear to be >> OpenEmbedded environments. >> >> Thanks, >> >> Robert Munro >> >> *From:*Chris Hinkey <chinkey@geontech.com> >> *Sent:* Wednesday, July 17, 2019 4:34 PM >> *To:* James Kulp <jek@parera.com> >> *Cc:* Munro, Robert M. <Robert.Munro@jhuapl.edu>; >> discuss@lists.opencpi.org >> *Subject:* Re: [Discuss OpenCPI] Issue building OCPI components using >> new RCC platform based on N310 SDK >> >> I think I am running in to a same/similar problem today with a yocto >> based toolchain that requires a environmental script be called prior >> to using it. >> >> the way rcc workers are built by calling the compiler executables >> directly instead of using the standard variables will likley cause >> similar build errors to these when building in both of these instances >> right? >> >> environment script: >> >> # Check for LD_LIBRARY_PATH being set, which can break SDK and >> generally is a bad practice # >> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN8 >> 0 # http://xahlee.info/UnixResource_dir/_/ldpath.html >> # Only disable this check if you are absolutely know what you are doing! >> if [ ! -z "$LD_LIBRARY_PATH" ]; then >> echo "Your environment is misconfigured, you probably need to >> 'unset LD_LIBRARY_PATH'" >> echo "but please check why this was set in the first place and >> that it's safe to unset." >> echo "The SDK will not operate correctly in most cases when >> LD_LIBRARY_PATH is set." >> echo "For more references see:" >> echo " >> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80" >> echo " http://xahlee.info/UnixResource_dir/_/ldpath.html" >> return 1 >> fi >> export >> SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux >> export >> PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/ho >> me/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chin >> key/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchai >> n/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/ >> x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey >> /toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/h >> ome/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-po >> ky-linux-musl:$PATH export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT >> export >> PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/ >> usr/share/pkgconfig export >> CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux >> export >> OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux" >> export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT" >> export OECORE_ACLOCAL_OPTS="-I >> /home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal" >> export OECORE_BASELIB="lib" >> export OECORE_TARGET_ARCH="aarch64" >> export OECORE_TARGET_OS="linux" >> unset command_not_found_handle >> export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT" >> export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT" >> export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT" >> export AS="aarch64-poky-linux-as " >> export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT" >> export GDB=aarch64-poky-linux-gdb >> export STRIP=aarch64-poky-linux-strip >> export RANLIB=aarch64-poky-linux-ranlib export >> OBJCOPY=aarch64-poky-linux-objcopy >> export OBJDUMP=aarch64-poky-linux-objdump >> export AR=aarch64-poky-linux-ar >> export NM=aarch64-poky-linux-nm >> export M4=m4 >> export TARGET_PREFIX=aarch64-poky-linux- export >> CONFIGURE_FLAGS="--target=aarch64-poky-linux >> --host=aarch64-poky-linux --build=x86_64-linux >> --with-libtool-sysroot=$SDKTARGETSYSROOT" >> export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " >> export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types " >> export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" >> export CPPFLAGS="" >> export KCFLAGS="--sysroot=$SDKTARGETSYSROOT" >> export OECORE_DISTRO_VERSION="2.6.2" >> export OECORE_SDK_VERSION="2.6.2" >> export ARCH=arm64 >> export CROSS_COMPILE=aarch64-poky-linux- >> >> # Append environment subscripts >> if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then >> for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do >> . $envfile >> done >> fi >> if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then >> for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do >> . $envfile >> done >> fi >> >> On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek@parera.com >> <mailto:jek@parera.com>> wrote: >> >> Robert, >> >> Ok. Since Ettus SDKs are certainly something we need to deal with, I >> looked into this carefully. >> I had to make some OpenCPI patches to support cross tools that >> required >> extra command line and environment info like these do. >> Our previous cross-tools (4 or 5, including some altera/arm and other >> xilinx sdk ones) did not require this. >> I now have a clean build of all the prereqs and the framework itself >> using this tool set. >> How/where did you get the kernel headers from Ettus? The OpenCPI >> kernel >> driver is the last software thing to build. >> >> I'll be sending a proper patch in a few days so it can be applied to >> release 1.5 (which will be posted in the next day or so). >> Thanks for the info on this so we can support this sort of thing >> better >> going forward. >> >> Jim >> >> On 7/16/19 4:54 PM, Munro, Robert M. wrote: >> > Jim, >> > >> > Attached here. >> > >> > I believe it was attached with the original message to show how >> the environment is being specified to the framework along with >> request to know any variables that are necessary or incorrect. >> > >> > Thanks, >> > Robert Munro >> > >> > -----Original Message----- >> > From: James Kulp <jek@parera.com <mailto:jek@parera.com>> >> > Sent: Tuesday, July 16, 2019 4:45 PM >> > To: Munro, Robert M. <Robert.Munro@jhuapl.edu >> <mailto:Robert.Munro@jhuapl.edu>>; discuss@lists.opencpi.org >> <mailto:discuss@lists.opencpi.org> >> > Subject: Re: [Discuss OpenCPI] Issue building OCPI components >> using new RCC platform based on N310 SDK >> > >> > One more request: can you send what you are using for >> ettus_n310_sdk.mk <http://ettus_n310_sdk.mk>? >> > Basically I want to discover where we are sensitive to certain >> environment settings and should not be. >> > Our builds go to some length to make sure everything relevant is >> specified in the file, and nothing depends on the environment. >> > >> > Thanks. >> > >> > On 7/15/19 12:52 PM, Munro, Robert M. wrote: >> >> Jim, >> >> >> >> It looks like the compilation executable environment variables >> are being overridden. In the sourced SDK environment the CC, CXX, >> and LD variables are more than the executable but the OCPI >> environment does not appear to take in the OcpiCFlags and >> OcpiCXXFlags that are defined in ettus_n310_sdk.mk >> <http://ettus_n310_sdk.mk>. >> >> >> >> Attached output from the env and printenv commands. >> >> >> >> The install-ad9361.sh script was found and followed to generate >> the required library for assets project compilation. The script >> build/build-opencpi.sh ettus_n310-sdk was run in an attempt to >> build the entire framework but it failed when attempting to build >> its first application with errors stating that ld is unable to >> find crt*.o and multiple libraries that it is attempting to link. >> >> >> >> Thanks, >> >> Robert Munro >> >> >> >> -----Original Message----- >> >> From: James Kulp <jek@parera.com <mailto:jek@parera.com>> >> >> Sent: Monday, July 15, 2019 10:46 AM >> >> To: Munro, Robert M. <Robert.Munro@jhuapl.edu >> <mailto:Robert.Munro@jhuapl.edu>>; >> >> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> >> >> Subject: Re: [Discuss OpenCPI] Issue building OCPI components using >> >> new RCC platform based on N310 SDK >> >> >> >> Yes the compiler flags are the issue - I'm just trying to >> figure out where they are coming from. >> >> >> >> Prerequisite build scripts are in three places: >> >> 1. Framework prerequisites in build/prerequisites 2. >> Per-project prerequisites in the prerequisites subdirectory of >> projects 3. Per-platform prerequisites (like installing a >> cross-compiler), in the rcc platform's directory. >> >> >> >> >> >> On 7/15/19 10:34 AM, Munro, Robert M. wrote: >> >>> Jim, >> >>> >> >>> Agreed that the difference between the calls from within >> install-prerequisites.sh and direct is the environment being >> used. It's likely the important difference being the parameters >> passed to gcc and g++ applications shown as the additional >> '-march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 >> --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux-gnueabi' >> in the direct call. I can work on posting a more complete >> environment listing, but suspect this difference will be important. >> >>> >> >>> Does the install-prerequisites.sh script override the $CC and >> $CXX environment variables which removes the additional flags? I >> believed that by specifying the additional flags in the >> ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> they would be part of >> the environment as they are when compiling projects using 'ocpidev >> build project ... -rcc-platform ettus_n310_sdk' . >> >>> >> >>> The build/autotools components completed a build manually with >> some modifications to autotools/gen/configure. The lines where >> -Werror=null-dereference and -Werror=maybe-uninitialized are added >> to compiler flag lists needed to be commented. I was not sure how >> to correctly remove the compilation flags in this case. >> >> Any changes to compilation flags are in the .mk file for the >> platform, >> >> including overriding defaults. >> >> >> >> But those flags (the "error" ones) should only be used with >> framework >> >> code which is clean for them. >> >> >> >> Obviously we are interested in seeing whatever patches you found as >> >> required. >> >> >> >>> Where are the compilation steps required for the ad9361 >> library described? That prerequisite is currently preventing the >> compilation of the assets project. >> >>> >> >>> Thanks, >> >>> Robert Munro >> >>> >> >>> -----Original Message----- >> >>> From: discuss <discuss-bounces@lists.opencpi.org >> <mailto:discuss-bounces@lists.opencpi.org>> On Behalf Of James >> >>> Kulp >> >>> Sent: Monday, July 15, 2019 8:52 AM >> >>> To: discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> >> >>> Subject: Re: [Discuss OpenCPI] Issue building OCPI components >> using >> >>> new RCC platform based on N310 SDK >> >>> >> >>> Hi Robert, >> >>> >> >>> Thanks for the report. >> >>> So the configure commands are the same in both cases, but are >> run in different environments. >> >>> Perhaps you could dump the environment along with the set -x >> >>> >> >>> Jim >> >>> >> >>> >> >>> On 7/12/19 5:53 PM, Munro, Robert M. wrote: >> >>>> OCPI Development Team, >> >>>> >> >>>> An Ettus N310 SDK environment is being integrated into the >> OCPI build environment to enable building software for the N310 >> target. The RCC platform has been set up and the core project >> appears to build successfully using 'ocpidev build project >> projects/core -rcc -rcc-platform ettus_n310_sdk'. >> >>>> >> >>>> When attempting to build the assets project the compiler >> throws an error when it doesn't find some libraries from the >> prerequisites. I have attempted using the command >> 'build/install-prerequisites.sh ettus_n310_sdk' to build and >> install all required prerequisites, but this fails in the >> configure operation of gmp. By navigating to the >> prerequisites-build/gmp/gmp-6.1.2/ocpi-build-ettus_n310_sdk/ and >> running the prescribed configure, make, make install commands the >> build completes without error. To see the difference between the >> two commands 'set +x .. set -x' was added around the configure >> command in build/prerequisites/gmp/install-gmp.sh . >> >>>> >> >>>> Failing configure command: >> >>>> ../configure --host=arm-oe-linux-gnueabi >> >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp >> >>>> >> --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et >> >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic >> >>>> >> >>>> Failing configure output: >> >>>> checking whether >> >>>> >> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- >> >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc is gcc... yes checking >> >>>> compiler >> >>>> >> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe- >> >>>> li nux-gnueabi/arm-oe-linux-gnueabi-gcc -O2 -pipe -g >> >>>> -feliminate-unused-debug-types ... no >> >>>> configure: error: could not find a working compiler, see >> config.log >> >>>> for details >> >>>> >> >>>> Working configure command: >> >>>> ../configure --host=arm-oe-linux-gnueabi >> >>>> --prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp >> >>>> >> --exec-prefix=/home/me/work/me/geontech/opencpi/prerequisites/gmp/et >> >>>> tu s_n310_sdk --enable-fat=yes --enable-cxx=yes --with-pic >> >>>> >> >>>> Working configure output: >> >>>> checking whether arm-oe-linux-gnueabi-gcc -march=armv7-a -marm >> >>>> -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 >> >>>> >> --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux >> >>>> -g nueabi is gcc... yes checking compiler >> arm-oe-linux-gnueabi-gcc >> >>>> -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 >> >>>> >> --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-neon-oe-linux >> >>>> -g nueabi -O2 -pipe -g -feliminate-unused-debug-types ... yes >> >>>> >> >>>> Since the install-prerequisites.sh script fails in gmp >> library, the liquid, lzma, and gtest libraries must be built and >> succeed using a similar manual approach. The assets project is >> then able to build several RCC elements until it reaches the >> ad9361_config_proxy.so where it is looking for the libad9361.a . >> After searching in similar places as the build steps for the other >> prerequisites (build/prerequisites/<library>) the appropriate >> instructions for manually building the ad9361 library are not able >> to be found. Where are the build steps described for this library? >> >>>> >> >>>> Likewise the build of the build/autotools/ products using >> this SDK requires manual configuration and is currently failing to >> complete. >> >>>> >> >>>> Is the use of a non-Xilinx SDK unsupported for the framework >> or are there more elements that can be supplied to the framework >> to support this use case? A copy of the RCC configuration file is >> attached for reference. >> >>>> >> >>>> Thank you, >> >>>> Robert Munro >> >>>> -------------- next part -------------- An HTML attachment was >> >>>> scrubbed... >> >>>> URL: >> >>>> >> <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach >> >>>> me nts/20190712/d87a4d9e/attachment.html> >> >>>> -------------- next part -------------- A non-text attachment was >> >>>> scrubbed... >> >>>> Name: ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> >> >>>> Type: application/octet-stream >> >>>> Size: 2431 bytes >> >>>> Desc: ettus_n310_sdk.mk <http://ettus_n310_sdk.mk> >> >>>> URL: >> >>>> >> <http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attach >> >>>> me nts/20190712/d87a4d9e/attachment.mk <http://attachment.mk>> >> >>>> _______________________________________________ >> >>>> discuss mailing list >> >>>> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> >> >>>> >> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org >> >>> _______________________________________________ >> >>> discuss mailing list >> >>> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> >> >>> >> >> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org >> >> >> >> _______________________________________________ >> discuss mailing list >> discuss@lists.opencpi.org <mailto:discuss@lists.opencpi.org> >> >> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org >>

discuss@lists.opencpi.org

Issue building OCPI components using new RCC platform based on N310 SDK

Check for LD_LIBRARY_PATH being set, which can break SDK and generally is

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80

http://xahlee.info/UnixResource_dir/_/ldpath.html

Only disable this check if you are absolutely know what you are doing!

Append environment subscripts

Check for LD_LIBRARY_PATH being set, which can break SDK and generally is a bad practice

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80

http://xahlee.info/UnixResource_dir/_/ldpath.html

Only disable this check if you are absolutely know what you are doing!

Append environment subscripts

< PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.local/bin:/home/jek/bin

Check for LD_LIBRARY_PATH being set, which can break SDK and

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80

http://xahlee.info/UnixResource_dir/_/ldpath.html

Only disable this check if you are absolutely know what you are doing!

Append environment subscripts

< PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/hom e/jek/.local/bin:/home/jek/bin

Check for LD_LIBRARY_PATH being set, which can break SDK and

Only disable this check if you are absolutely know what you are doing!

Append environment subscripts

< PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/hom e/jek/.local/bin:/home/jek/bin

Check for LD_LIBRARY_PATH being set, which can break SDK and

Only disable this check if you are absolutely know what you are doing!

Append environment subscripts

<
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/jek/.local/bin:/home/jek/bin

<
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/hom
e/jek/.local/bin:/home/jek/bin

<
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/hom
e/jek/.local/bin:/home/jek/bin