MR
Munro, Robert M.
Fri, Jul 12, 2019 9:53 PM
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/ettus_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-linux-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-linux-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/ettus_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-gnueabi 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-gnueabi -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
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/ettus_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-linux-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-linux-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/ettus_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-gnueabi 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-gnueabi -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
JK
James Kulp
Mon, Jul 15, 2019 12:52 PM
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/ettus_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-linux-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-linux-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/ettus_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-gnueabi 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-gnueabi -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
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/ettus_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-linux-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-linux-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/ettus_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-gnueabi 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-gnueabi -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
>
MR
Munro, Robert M.
Mon, Jul 15, 2019 2:34 PM
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.
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/ettu
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/ettu
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/attachme
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/attachme
nts/20190712/d87a4d9e/attachment.mk>
discuss mailing list
discuss@lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
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.
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/ettu
> 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/ettu
> 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/attachme
> 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/attachme
> 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
JK
James Kulp
Mon, Jul 15, 2019 2:45 PM
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
- Per-project prerequisites in the prerequisites subdirectory of projects
- 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/ettu
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/ettu
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/attachme
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/attachme
nts/20190712/d87a4d9e/attachment.mk>
discuss mailing list
discuss@lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
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/ettu
>> 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/ettu
>> 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/attachme
>> 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/attachme
>> 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
MR
Munro, Robert M.
Mon, Jul 15, 2019 4:52 PM
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/ettu
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/ettu
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/attachme
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/attachme
nts/20190712/d87a4d9e/attachment.mk>
discuss mailing list
discuss@lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
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/ettu
>> 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/ettu
>> 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/attachme
>> 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/attachme
>> 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
JK
James Kulp
Mon, Jul 15, 2019 7:39 PM
Thanks. Is it easy to import the SDK you are using so we can reproduce
the environment?
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/ettu
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/ettu
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/attachme
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/attachme
nts/20190712/d87a4d9e/attachment.mk>
discuss mailing list
discuss@lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
Thanks. Is it easy to import the SDK you are using so we can reproduce
the environment?
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/ettu
>>> 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/ettu
>>> 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/attachme
>>> 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/attachme
>>> 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
>
MR
Munro, Robert M.
Mon, Jul 15, 2019 8:00 PM
James,
The N310 SDK can be downloaded from the Ettus file servers. There are multiple versions located in the meta-ettus-<version>/ directories located in https://files.ettus.com/binaries/cache/n3xx/ . The versions should be similar until building for a specific kernel. My development environment currently has the 3.13.0.2-20180829 version installed.
Downloading and running the bash script extracted from the n3xx_common_sdk_default-<version>.zip will install the SDK in your environment. Sourcing and using the SDK is discussed in Ettus' documentation here https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_sdkusage .
Thanks,
Rob
-----Original Message-----
From: James Kulp jek@parera.com
Sent: Monday, July 15, 2019 3:40 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
Thanks. Is it easy to import the SDK you are using so we can reproduce the environment?
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
James,
The N310 SDK can be downloaded from the Ettus file servers. There are multiple versions located in the meta-ettus-<version>/ directories located in https://files.ettus.com/binaries/cache/n3xx/ . The versions should be similar until building for a specific kernel. My development environment currently has the 3.13.0.2-20180829 version installed.
Downloading and running the bash script extracted from the n3xx_common_sdk_default-<version>.zip will install the SDK in your environment. Sourcing and using the SDK is discussed in Ettus' documentation here https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_sdkusage .
Thanks,
Rob
-----Original Message-----
From: James Kulp <jek@parera.com>
Sent: Monday, July 15, 2019 3:40 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
Thanks. Is it easy to import the SDK you are using so we can reproduce the environment?
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
>
JK
James Kulp
Tue, Jul 16, 2019 8:45 PM
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/ettu
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/ettu
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/attachme
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/attachme
nts/20190712/d87a4d9e/attachment.mk>
discuss mailing list
discuss@lists.opencpi.org
http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
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/ettu
>>> 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/ettu
>>> 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/attachme
>>> 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/attachme
>>> 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
>
MR
Munro, Robert M.
Tue, Jul 16, 2019 8:54 PM
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
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
>
JK
James Kulp
Wed, Jul 17, 2019 4:24 PM
Thanks.
I am working through some of these issues.
Basically there are about 5 different ways that people set up
cross-compilers, and this one falls into the "run a special script and
pollute the user's environment" category.
Many others use internal spec files that are found relative to the cross
compiler executables, which requires no environment set up at all.
Some packages, when they do "configure", have built-in config rules that
set compiler flags based on architectures and/or compilers.
Our "platform definition" files tries to capture all required settings
in a version controlled file that is has a common form across all
supported cross-compilers, regardless of their "style".
But when we build prerequisites, we generally have used the default
settings of the cross-compilers.
gmp failed in this case because it expected the appropriate flags to be
set as part of its configure process, whereas this cross-compiler
expects them explicitly in the environment,
which of course makes it painful to run multiple cross compilers in the
same environment.
It was easy enough to fix this in this case by changing the gmp
installation script, but that creates conflicts for other cross-compilers.
I'm developing a "clean" fix that does not fail on other cross compilers....
We should have a paragraph or two on dealing with this type of
cross-compiler....
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
Thanks.
I am working through some of these issues.
Basically there are about 5 different ways that people set up
cross-compilers, and this one falls into the "run a special script and
pollute the user's environment" category.
Many others use internal spec files that are found relative to the cross
compiler executables, which requires no environment set up at all.
Some packages, when they do "configure", have built-in config rules that
set compiler flags based on architectures and/or compilers.
Our "platform definition" files tries to capture all required settings
in a version controlled file that is has a common form across all
supported cross-compilers, regardless of their "style".
But when we build prerequisites, we generally have used the default
settings of the cross-compilers.
gmp failed in this case because it expected the appropriate flags to be
set as part of its configure process, whereas this cross-compiler
expects them explicitly in the environment,
which of course makes it painful to run multiple cross compilers in the
same environment.
It was easy enough to fix this in this case by changing the gmp
installation script, but that creates conflicts for other cross-compilers.
I'm developing a "clean" fix that does not fail on other cross compilers....
We should have a paragraph or two on dealing with this type of
cross-compiler....
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
