Geontech / meta-redhawk-sdr

REDHAWK SDR Layer for Yocto/OpenEmbedded -based deployments
http://geontech.com/getting-started-with-meta-redhawk-sdr/
GNU Lesser General Public License v3.0
9 stars 6 forks source link

Error while building redhawk-bulkio_2.0.4 #5

Closed rodrigo455 closed 7 years ago

rodrigo455 commented 7 years ago

log.do_compile.txt Hello,

I'm trying to bitbake for usrp e310... I'm getting this error of bad instruction while building redhawk-bulkio:

... {standard input}:365797: Error: bad instruction incl [r3,#4]' | {standard input}:365893: Error: bad instructionlock' | {standard input}:365894: Error: bad instruction incl [r2,#4]' | make[1]: *** [cpp/libbulkio_2.0_la-bulkio_in_port.lo] Error 1 | make[1]: Leaving directory/home/fmce794/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/redhawk-bulkio/2.0.4-r0/git/bulkioInterfaces/libsrc' | make: *** [all-recursive] Error 1 | ERROR: oe_runmake failed | WARNING: /home/fmce794/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/redhawk-bulkio/2.0.4-r0/temp/run.do_compile.8753:1 exit 1 from | exit 1 | ERROR: Function failed: do_compile (log file is located at /home/fmce794/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/redhawk-bulkio/2.0.4-r0/temp/log.do_compile.8753) ERROR: Task 1521 (/home/fmce794/e300-oe-build/oe-core/../meta-redhawk-sdr/recipes-redhawk/redhawk-bulkio/redhawk-bulkio_2.0.4.bb, do_compile) failed with exit code '1'

any ideas why this is happening? a do_compile log is attached. thanks!

patcamwol commented 7 years ago

Hello,

Would you mind running the following and uploading the bitbakeEnvironment.txt file:

$ bitbake -e IMAGE > bitbakeEnvironment.txt

Where IMAGE is whatever image you were trying to build, presumably redhawk-usrp-uhd-image or something similar.

Thanks, Patrick

rodrigo455 commented 7 years ago

bitbakeEnvironment.txt here it is

patcamwol commented 7 years ago

All right, what version of bitbake are you using (bitbake --version) and which branch of the meta-ettus layer are you using? Also, what linux distribution are you using on your build machine?

rodrigo455 commented 7 years ago

bitbake --version BitBake Build Tool Core version 1.26.0, bitbake version 1.26.0 repo info Project: bitbake Current revision: b09966906ef054834f0b465f0c5a2a937b4c4a4c Project: meta-ettus Current revision: 40cf300296b889df5b8445bf7db457c160220919 Project: meta-openembedded Current revision: e8a8e0be8e39dbb949bf0f0df90abe1c4e3f6470 Project: meta-sdr Current revision: 3d06bc06e874dc3b8db64fc1bf838763f834d193 Project: meta-xilinx Current revision: 13779b9254bab450875a60ed8f21edd0e8876a71 Project: openembedded-core Current revision: 9f339f516ab03d598fae0e536b3a420ea4d8ee1a CentOs 7 uname -a Linux localhost.localdomain 3.10.0-514.16.1.el7.x86_64 #1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

is there a command to clean the whole build? thanks so far.

rodrigo455 commented 7 years ago

I fresh build everything again, but still with a problem building bulkio: log.do_compile.txt

kioInterfaces.so.2 -o .libs/libbulkioInterfaces.so.2.1.0 | /home/fmce794/Desktop/e300-oe-build/build/tmp-glibc/sysroots/x86_64-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.9.2/ld: cannot find -lossiecf | /home/fmce794/Desktop/e300-oe-build/build/tmp-glibc/sysroots/x86_64-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.9.2/ld: cannot find -lossieidl | collect2: error: ld returned 1 exit status | make[1]: [libbulkioInterfaces.la] Error 1 | make[1]: Leaving directory `/home/fmce794/Desktop/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/redhawk-bulkio/2.0.4-r0/git/bulkioInterfaces' | make: [all-recursive] Error 1 | ERROR: oe_runmake failed | WARNING: /home/fmce794/Desktop/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/redhawk-bulkio/2.0.4-r0/temp/run.do_compile.8745:1 exit 1 from | exit 1 | ERROR: Function failed: do_compile (log file is located at /home/fmce794/Desktop/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/redhawk-bulkio/2.0.4-r0/temp/log.do_compile.8745) ERROR: Task 1521 (/home/fmce794/Desktop/e300-oe-build/oe-core/../meta-redhawk-sdr/recipes-redhawk/redhawk-bulkio/redhawk-bulkio_2.0.4.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 3047 tasks of which 0 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish:

Summary: 1 task failed: /home/fmce794/Desktop/e300-oe-build/oe-core/../meta-redhawk-sdr/recipes-redhawk/redhawk-bulkio/redhawk-bulkio_2.0.4.bb, do_compile Summary: There were 15 WARNING messages shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code. Bitbake build image failed

it cannot find the libraries to link because it's looking into a path that does not exist: ...e300-oe-build/build/tmp-glibc/sysroots/ettus-e3xx-sg1/usr/local/redhawk/core/lib64

patcamwol commented 7 years ago

All right, that's a much more familiar looking error. I will try to recreate that tonight and send you the solution tomorrow.

patcamwol commented 7 years ago

I ran a build last night but ran out of disk space. Fixed that and starting another one right now. I'll try to get you the solution tonight. Sorry for the delay

rodrigo455 commented 7 years ago

no problem! thanks!

patcamwol commented 7 years ago

Ok, so I wasn't able to reproduce the error. But there's still hope.

If you don't already have docker installed, go ahead and do that, please: https://docs.docker.com/engine/installation/linux/centos/

Once that's ready, download this file: Dockerfile.rodrigo.txt

Copy that file to a directory by itself, then run the following: docker build --rm -t rodrigo-build -f Dockerfile.rodrigo.txt .

When that has finished, run the following: docker run --rm -it -v <some/path/on/host/with/space>:/build_rodrigo rodrigo-build /bin/bash

That should drop you into the same environment I used to get this built. To actually perform the build, run the template configuration command: TEMPLATECONF=pwd/poky/meta-ettus/conf source ./poky/oe-init-build-env ./build ./poky/bitbake

Finally, run the bitbake command: bitbake redhawk-usrp-uhd-image

If this works, then something about your host environment is corrupting your bitbake build, which isn't supposed to happen.

patcamwol commented 7 years ago

Actually, for the docker run command, replace :/build_rodrigo with :/build_rodrigo/build, then after you run the template configuration command, edit the conf/bblayers.conf to have the correct path and to include the meta-redhawk-sdr layer. That should allow all of your build artifacts to be mounted on your host system correctly.

rodrigo455 commented 7 years ago

In my previous failed build I followed Mr. Goodwin Instructions here: http://geontech.com/blog/redhawk-sdr-and-an-ettus-e310/

I made the environmet you gave me... now I am bitbaking. I'll tell you the results later. Is there any environment compatibility regarding those specific repositories versions gotten by "git checkout" inside the txt file that you attached before?

many thanks!

patcamwol commented 7 years ago

I'm not 100% sure why those would be so troublesome. This just guarantees that we are both dealing with the exact same system.

The git checkouts were simply to exactly replicate your environment from a previous comment. Are you using MACHINE=ettus-e3xx-sg1?

rodrigo455 commented 7 years ago

I understand... Yes, I am using MACHINE="ettus-e3xx-sg1"... acording to the USRP Manual https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_image_building

rodrigo455 commented 7 years ago

it worked! it's built... I still don't know what was wrong with the previous environment though... Thank you!

btgoodwin commented 7 years ago

If you have REDHAWK SDR installed on the host operating system at the same time you're trying to bitbake it for a target, you may see errors similar to what you were seeing (not saying this is the cause, but it very well could have been since containerizing the build resolved your errors).

The reason is the use of the OSSIEHOME in the build process (i.e., the actual source code, not this layer). To get around this on a recent target, I modified the redhawk-env.bbclass location to be different than my host OS. That fixed the issue for me, so I pushed that fix since it's bound to come up for others.

I apologize for the tardy response as well; I was out when I saw Patrick pick this thread up. I'm glad he was able to get you going with a Docker-based build. It really ensures a consistently sanitized build environment.

I'm going to go ahead and close this issue since it seems to be resolved with a couple go-paths around problems like these. Thanks for bringing it to our attention @rodrigo455. 👍