I think I am running in to a same/similar problem today with a yocto based
toolchain that requires a environmental script be called prior to using
it.
the way rcc workers are built by calling the compiler executables directly
instead of using the standard variables will likley cause similar build
errors to these when building in both of these instances right?
environment script:
# Check for LD_LIBRARY_PATH being set, which can break SDK and generally is
a bad practice
#
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
#
http://xahlee.info/UnixResource_dir/_/ldpath.html
# Only disable this check if you are absolutely know what you are doing!
if [ ! -z "$LD_LIBRARY_PATH" ]; then
echo "Your environment is misconfigured, you probably need to 'unset
LD_LIBRARY_PATH'"
echo "but please check why this was set in the first place and that
it's safe to unset."
echo "The SDK will not operate correctly in most cases when
LD_LIBRARY_PATH is set."
echo "For more references see:"
echo "
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80"
echo "
http://xahlee.info/UnixResource_dir/_/ldpath.html"
return 1
fi
export SDKTARGETSYSROOT=/home/chinkey/toolchain/sysroots/aarch64-poky-linux
export
PATH=/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/sbin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux:/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux-musl:$PATH
export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export
PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig
export CONFIG_SITE=/home/chinkey/toolchain/site-config-aarch64-poky-linux
export
OECORE_NATIVE_SYSROOT="/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
export OECORE_ACLOCAL_OPTS="-I
/home/chinkey/toolchain/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export OECORE_BASELIB="lib"
export OECORE_TARGET_ARCH="aarch64"
export OECORE_TARGET_OS="linux"
unset command_not_found_handle
export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT"
export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT"
export CPP="aarch64-poky-linux-gcc -E --sysroot=$SDKTARGETSYSROOT"
export AS="aarch64-poky-linux-as "
export LD="aarch64-poky-linux-ld --sysroot=$SDKTARGETSYSROOT"
export GDB=aarch64-poky-linux-gdb
export STRIP=aarch64-poky-linux-strip
export RANLIB=aarch64-poky-linux-ranlib
export OBJCOPY=aarch64-poky-linux-objcopy
export OBJDUMP=aarch64-poky-linux-objdump
export AR=aarch64-poky-linux-ar
export NM=aarch64-poky-linux-nm
export M4=m4
export TARGET_PREFIX=aarch64-poky-linux-
export CONFIGURE_FLAGS="--target=aarch64-poky-linux
--host=aarch64-poky-linux --build=x86_64-linux
--with-libtool-sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types "
export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
export CPPFLAGS=""
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
export OECORE_DISTRO_VERSION="2.6.2"
export OECORE_SDK_VERSION="2.6.2"
export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-
# Append environment subscripts
if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then
for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do
. $envfile
done
fi
if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then
for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do
. $envfile
done
fi
On Wed, Jul 17, 2019 at 3:19 PM James Kulp <jek_at_parera.com> wrote:
> Robert,
>
> Ok. Since Ettus SDKs are certainly something we need to deal with, I
> looked into this carefully.
> I had to make some OpenCPI patches to support cross tools that required
> extra command line and environment info like these do.
> Our previous cross-tools (4 or 5, including some altera/arm and other
> xilinx sdk ones) did not require this.
> I now have a clean build of all the prereqs and the framework itself
> using this tool set.
> How/where did you get the kernel headers from Ettus? The OpenCPI kernel
> driver is the last software thing to build.
>
> I'll be sending a proper patch in a few days so it can be applied to
> release 1.5 (which will be posted in the next day or so).
> Thanks for the info on this so we can support this sort of thing better
> going forward.
>
> Jim
>
> On 7/16/19 4:54 PM, Munro, Robert M. wrote:
> > Jim,
> >
> > Attached here.
> >
> > I believe it was attached with the original message to show how the
> environment is being specified to the framework along with request to know
> any variables that are necessary or incorrect.
> >
> > Thanks,
> > Robert Munro
> >
> > -----Original Message-----
> > From: James Kulp <jek_at_parera.com>
> > Sent: Tuesday, July 16, 2019 4:45 PM
> > To: Munro, Robert M. <Robert.Munro_at_jhuapl.edu>;
> discuss_at_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_at_parera.com>
> >> Sent: Monday, July 15, 2019 10:46 AM
> >> To: Munro, Robert M. <Robert.Munro_at_jhuapl.edu>;
> >> discuss_at_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_at_lists.opencpi.org> On Behalf Of James
> >>> Kulp
> >>> Sent: Monday, July 15, 2019 8:52 AM
> >>> To: discuss_at_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_at_lists.opencpi.org
> >>>> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
> >>> _______________________________________________
> >>> discuss mailing list
> >>> discuss_at_lists.opencpi.org
> >>> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
>
>
>
> _______________________________________________
> discuss mailing list
> discuss_at_lists.opencpi.org
> http://lists.opencpi.org/mailman/listinfo/discuss_lists.opencpi.org
>
Received on Wed Jul 17 2019 - 20:34:20 CDT