I can successfully build and run a MIPS image on my target device. I use a command such as:
bitbake <image-name>
I also want to be able to build an executable (and all its dependencies) that is part of the same image, to run on my x86_64 host. Using my image configuration of build above, I can execute a partial build of my image simply by giving the following command:
bitbake <name-of-executable>
Obviously, without any changes the executable (and all its dependencies) will be a MIPS-build.
What do I have to change to have the executable (and all its dependencies) be built to run on my developer machine, an x86_64?
You would need to build a -native version of your recipe.
Often, this is possible by adding the following line to your recipe, example.bb:
BBCLASSEXTEND = "native"
That would allow you to call bitbake example to still create the package for MIPS, while allowing you to call bitbake example-native to create a package / binary to be used within the bitbake environment. (I.e. it's built for x86_64 in your case).
Related
I am trying to build an application that communicates with dds with opendds. I am using the opendds layer on krikstone. The bitbake image is built with the opendds libraries but when I build the sdk it seems the layer nativesdk is not installed. When I run the cmake I get the error "Missing required dependencies OPENDDS_IDL;ACE_GPERF;TAO_IDL".
from the opendds.inc I see there is the nativesdk install. I added a junk line and expected that when i build the opendds or build the populate-sdk I will fail but it seems that the nativesdk is not run.
build is for imx8mm variscite som with command bitbake fsl-image-qt5 -v populate_sdk_ext
layer with the problem is meta-opendds (krikstone branch) building version 3.22
the layer has a bb file that requires an opendds.inc file which has the nativesdk install
Blockquote
do_install:append:class-nativesdk() {
dfdf -- my junk line to trigger failure
ln -sf ${bindir}/opendds_idl ${D}${datadir}/dds/bin/opendds_idl
ln -sf ${bindir}/ace_gperf ${D}${datadir}/ace/bin/ace_gperf
ln -sf ${bindir}/tao_idl ${D}${datadir}/ace/bin/tao_idl
}
Blockquote
** i added a junk line to trigger failure but it doesnt fail with building the sdk or image itself
why is the nativesdk command not run and why is the sdk without the opendds_idl executable
thanks
I was able at last to build the nativesdk files. I had to build them specifically as they are not build by default. i had to "bitbake nativesdk-opendds" manually.
my mistake was to believe that the nativesdk will be defaulted. my assumption is that if i am using the opendds that most probable that i will build subscribers/produces applications and will need the opendds_idl executable.
!!!! after testing the nativesdk-opendds it did not solve the problem !!!
!! in general after adding building the opendds layer i cannot build the Messanger example for lack of the opendds_idl and other two (tao,ace) executable
I'm currently encountering an issue whereby the version of OpenCV being included in the target image is different to that which is being included in the host SDK (3.4.x as opposed to 3.3.x).
In order to better debug this, I want to list the packages (and their versions) which will be included in the host SDK produced by bitbake core-image-weston -c populate_sdk.
How can I do this? Note: I'm using the command line and am not using Toaster.
Thanks in advance.
One good way to debug such package or sdk issues is yocto buildhistory
Add the content below to your local.conf
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
BUILDHISTORY_FEATURES = "image package sdk" # maybe already default value
A new folder will be created under build/buildhistory/ , which allows you to verify packages, sdk and the image in a easy manner.
Edit:
Since you want it before compiling everything:
bitbake -g core-image-weston -c populate_sdk && cat pn-buildlist | sort | uniq | bitbake -s > dependencies
I've been trying to install Tensorflow and get it working over the past few days. Whilst I have managed to install TF and get it working as tested by opening Python in the terminal and typing,
import tensorflow as tf
I have not been successful attempting to retrain Inception v3. I managed to install it from source once by following the instructions laid out here however I am no longer able to do so. When I get to the section 'Create the pip package and install' and go to run bazel build -c opt //tensorflow/tools/pip_package:build_pip_package in the root of my Tensorflow directiory I get the following error.
kieran#kieranUbuntu:~/tensorflow$ bazel build -c opt //tensorflow/tools/pip_package:build_pip_package
ERROR: /home/kieran/tensorflow/tensorflow/core/BUILD:1068:1: no such target '//tensorflow/tools/git:gen/spec.json': target 'gen/spec.json' not declared in package 'tensorflow/tools/git' defined by /home/kieran/tensorflow/tensorflow/tools/git/BUILD and referenced by '//tensorflow/core:version_info_gen'.
ERROR: /home/kieran/tensorflow/tensorflow/core/BUILD:1068:1: no such target '//tensorflow/tools/git:gen/head': target 'gen/head' not declared in package 'tensorflow/tools/git' defined by /home/kieran/tensorflow/tensorflow/tools/git/BUILD and referenced by '//tensorflow/core:version_info_gen'.
ERROR: /home/kieran/tensorflow/tensorflow/core/BUILD:1068:1: no such target '//tensorflow/tools/git:gen/branch_ref': target 'gen/branch_ref' not declared in package 'tensorflow/tools/git' defined by /home/kieran/tensorflow/tensorflow/tools/git/BUILD and referenced by '//tensorflow/core:version_info_gen'.
ERROR: Analysis of target '//tensorflow/tools/pip_package:build_pip_package' failed; build aborted.
INFO: Elapsed time: 3.063s
This is the same error I ran into when I managed to install it and then attempted retaining the classifier following this tutorial. At the section, bazel build tensorflow/examples/image_retraining:retrain.
I just can't figure out what is going wrong and I have been trying for so long.
I'm using this pip version, # Ubuntu/Linux 64-bit, CPU only, Python 2.7
I think you should search before ask, This link can probably solve your issue.
The issue lied in the incorrect use of ./configure. Whilst it was ran I currently have two versions of python on my computer, both of which are stored in different locations, when running ./configure I pointed it to the wrong python version. After rectifying the issue everything worked correctly.
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I have a Yocto bitbake image recipe that can be built successfully.
However, the same image recipe fails when generating SDK with -c populate_sdk command.
The error seems to be caused by mixing 32-bit and 64-bit versions of libraries, which is fine when building images with only binaries, but the header files collide with each other when populating the SDK root fs:
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
file /usr/bin/curl-config from install of lib32-curl-dev-7.53.1-r0.cortexa7hf_neon_vfpv4 conflicts with file from package curl-dev-7.53.1-r0.aarch64
file /usr/include/nettle/version.h from install of lib32-nettle-dev-3.3-r0.cortexa7hf_neon_vfpv4 conflicts with file from package nettle-dev-3.3-r0.aarch64
file /usr/include/nettle/nettle-stdint.h from install of lib32-nettle-dev-3.3-r0.cortexa7hf_neon_vfpv4 conflicts with file from package nettle-dev-3.3-r0.aarch64
What is the best way to exclude 32-bit versions of libraries(recipes) when doing -c populate_sdk without excluding them entirely from the production image?
You can remove target packages from the toolchain by removing them from the TOOLCHAIN_TARGET_TASK variable and host packages by removing them from the TOOLCHAIN_HOST_TASK.
For example to remove the target package "curl-dev" from your sdk you have to add the following in your image recipe:
TOOLCHAIN_TARGET_TASK_remove = "curl-dev"
To remove the same host package from your sdk you have to add the following in your image recipe:
TOOLCHAIN_HOST_TASK_remove = "curl-dev"