I'm trying to build an image for the nvidia jetson nano board using yocto (zeus branch), here is my configuration:
Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = "jetson-nano"
DISTRO = "poky"
DISTRO_VERSION = "3.0.2"
TUNE_FEATURES = "aarch64 armv8a crc"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "zeus:5e1f52edb7a9f790fb6cb5d96502f3690267c1b1"
meta-python
meta-filesystems
meta-oe
meta-multimedia = "zeus:bb65c27a772723dfe2c15b5e1b27bcc1a1ed884c"
meta-tegra = "zeus:23a9f6c12a741b4067d7a2ee601b98c766850e47"
bu i'm getting the following error:
| /home/rui/projects/embeddeddfit/yocto/jetson-nano-build/tmp/work/armv8a_tegra210-poky-linux/cuda-samples/10.0.326-1-r0/recipe-sysroot/usr/local/cuda-10.0/include/crt/host_config.h:129:2: error: #error -- unsupported GNU version! gcc versions later than 7 are not supported!
| 129 | #error -- unsupported GNU version! gcc versions later than 7 are not supported!
| | ^~~~~
| Makefile:327: recipe for target 'UnifiedMemoryStreams.o' failed
| make: *** [UnifiedMemoryStreams.o] Error 1
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Execution of '/home/rui/projects/embeddeddfit/yocto/jetson-nano-build/tmp/work/armv8a_tegra210-poky-linux/cuda-samples/10.0.326-1-r0/temp/run.do_compile.24230' failed with exit code 1:
| test.c:1:10: fatal error: omp.h: No such file or directory
| 1 | #include <omp.h>
| | ^~~~~~~
| compilation terminated.
it seems to me that is a version compatibility problem.
in my local.conf i have:
MACHINE = "jetson-nano"
LICENSE_FLAGS_WHITELIST = "commercial"
IMAGE_CLASSES += "image_types_tegra"
IMAGE_FSTYPES = "tegraflash"
GCCVERSION = "7.%"
CUDA_VERSION="10.0"
IMAGE_INSTALL_append = " cuda-samples"
the 7.x version is specified but yocto don't found any compatible version
NOTE: Resolving any missing task queue dependencies
NOTE: preferred version 7.% of gcc-cross-aarch64 not available (for item virtual/aarch64-poky-linux-gcc)
NOTE: versions of gcc-cross-aarch64 available: 9.2.0
How can i force yocto to use 7.x version, or how can i make yocto detect 7.x versions?
The gcc recipes is located in
sources/poky/meta/recipes-devtools/gcc/
If you have a different version than what you want, you will have to download/make another recipe.
This is meta-tegra special sauce. Quote from README:
CUDA 10 supports up through gcc 7 only, and some NVIDIA-provided
binary libraries appear to be compiled with g++ 7 and cause linker
failures when building applications with g++ 6, so only gcc 7 should
be used if you intend to use CUDA. See the following wiki pages for
instructions on including gcc 7 in your builds:
Using gcc7 from the contrib layer
Using linaro gcc7 for CUDA support
In general, it's a good practice to read through the layer README when you start using a layer.
Related
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
The command pgxn install madlib get so many errors at UBUNTU 16 LTS (xenial)... There are a bug with MADLib installation for UBUNTU?
INFO: best version: madlib 1.10.0
INFO: saving /tmp/tmpZPEFvN/madlib-1.10.0.zip
INFO: unpacking: /tmp/tmpZPEFvN/madlib-1.10.0.zip
INFO: running configure
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is unknown
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error at CMakeLists.txt:14 (project):
The CMAKE_CXX_COMPILER:
sunCC;g++
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
CMake Error at /usr/share/cmake-3.5/Modules/CMakeCXXInformation.cmake:61 (include):
include called with wrong number of arguments. include() only takes one
file.
Call Stack (most recent call first):
CMakeLists.txt:14 (project)
-- Configuring incomplete, errors occurred!
See also "/tmp/tmpZPEFvN/madlib-1.10.0/build/CMakeFiles/CMakeOutput.log".
See also "/tmp/tmpZPEFvN/madlib-1.10.0/build/CMakeFiles/CMakeError.log".
INFO: building extension
make -C build all
make[1]: Entering directory '/tmp/tmpZPEFvN/madlib-1.10.0/build'
make[1]: *** No rule to make target 'all'. Stop.
make[1]: Leaving directory '/tmp/tmpZPEFvN/madlib-1.10.0/build'
Makefile:5: recipe for target 'all' failed
make: *** [all] Error 2
ERROR: command returned 2: make PG_CONFIG=/usr/bin/pg_config all
See also MADlib apt install, how to?
I've been following the "Getting Started" tutorial on http://swift.org. Upon creating new Swift "Hello World" project, I ran shell command:
$ swift build
and got the following output:
Compiling Swift Module 'MyProject' (1 sources)
Linking MyProject
ld: library not found for -lobjc
<unknown>:0: error: build had 1 command failures
error: exit(1): /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-02-25-a.xctoolchain/usr/bin/swift-build-tool -f /Users/petrmanek/Projekty/MyProject/.build/debug.yaml default
I'm assuming that ld: library not found for -lobjc means that the linker can't find the Objective-C standard library, however I find that hard to believe as both files /usr/lib/libobjc.A.dylib and /usr/lib/libobjc.dylib are present on my file system.
What do I do now?
My configuration is:
Hardware: Mac mini (Late 2012)
OS: Mac OS 10.11 El Capitan
uname -a
Darwin tywin 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
swift --version
Apple Swift version 3.0-dev (LLVM b361b0fc05, Clang 11493b0f62, Swift fc261045a5)
Target: x86_64-apple-macosx10.9
I think I have solved it. Here's my solution if anyone's interested.
Looking at the swift-build --help option list, I have discovered the option -Xlinker which allows me to specify flags directly for ld. I used this option to tell it to be more verbose with command:
$ swift build -Xlinker -v
The output was:
Linking MyProject
#(#)PROGRAM:ld PROJECT:ld64-242
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m armv7k arm64
Library search paths:
/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-02-25-a.xctoolchain/usr/lib/swift/macosx
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib
Framework search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/
ld: library not found for -lobjc
<unknown>:0: error: build had 1 command failures
error: exit(1): /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-02-25-a.xctoolchain/usr/bin/swift-build-tool -f /Users/petrmanek/Projekty/MyProject/.build/debug.yaml default
This was quite messy but we can see that /usr/lib is not among the library search paths. I had two options:
add /usr/lib as a search path - that didn't work because ld strives to add /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/ prefix in front of every search path I add using the -L flag
link `libobjc.dylib - that worked
Here are the shell commands I used (I did the same thing for libSystem because it required the same treatment):
$ cd /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-02-25-a.xctoolchain/usr/lib/swift/macosx
$ sudo ln -s /usr/lib/libobjc.dylib
$ sudo ln -s /usr/lib/libSystem.dylib
The swift build command is working now and the product runs correctly. However, I don't believe that is user-friendly installation process, Apple.
I am attempting to compile mongod.exe from github src but I keep running into the following error:
C:\Github\Mongo>scons --64 --ssl mongod.exe
scons: Reading SConscript files ...
scons version: 2.3.4
python version: 2 7 8 'final' 0
Checking whether the C++ compiler works... (cached) yes
Checking whether the C compiler works... (cached) yes
Checking if C++ compiler "$CC" is MSVC... (cached) yes
Checking if C compiler "cl" is MSVC... (cached) yes
Checking if C compiler is Microsoft Visual Studio 2013 Update 2 or newer...(cach
ed) yes
Checking if C++ compiler is Microsoft Visual Studio 2013 Update 2 or newer...(ca
ched) yes
Checking if target architecture is 32-bit x86...(cached) no
Checking if we are using libstdc++... (cached) no
Checking if we are on a POSIX system... (cached) no
Checking for __declspec(thread)... (cached) no
Checking for C++11 <atomic> support... (cached) no
Checking for C++ header file execinfo.h... (cached) no
Checking for C library pcap... (cached) no
Checking for C library wpcap... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
cl /Fobuild\win32\64\ssl\mongo\db\db.obj /c src\mongo\db\db.cpp /TP /nologo /EHs
c /W3 /wd4355 /wd4800 /wd4267 /wd4244 /wd4290 /wd4068 /wd4351 /we4099 /Z7 /error
Report:none /MT /O2 /Oy- /Gw /Gy /Zc:inline /DBOOST_ALL_NO_LIB /D_SCONS /DMONGO_
EXPOSE_MACROS /DSUPPORT_UTF8 /DMONGO_OPTIMIZED_BUILD /DMONGO_BYTE_ORDER=1234 /D_
UNICODE /DUNICODE /D_CONSOLE /D_CRT_SECURE_NO_WARNINGS /DMONGO_SSL /D_WIN32_WINN
T=0x0502 /DNTDDI_VERSION=0x05020200 /IC:\Github\winpcap\Include /Isrc\third_part
y\s2 /Isrc\third_party\pcre-8.30 /Isrc\third_party\boost /Ibuild\win32\64\ssl /I
src /Z7
db.cpp
C:\Github\Mongo\src\mongo/platform/atomic_intrinsics.h(60) : fatal error C1189:
#error : "Windows builds must use a compiler supporting std::atomic"
scons: *** [build\win32\64\ssl\mongo\db\db.obj] Error 2
scons: building terminated because of errors.
The source code throwing the error shows a variable _WIN32 as being defined and set to True but I thought the --64 option would have set this to false?
Any suggestions on how to resolve to complete a SSL build would be appreciated:
Environment: Visual Studio 2013, Window 7, x64 latest master from github
Observation: C++11 support is available when I run scons without --ssl and the compilation proceeds, but when using --ssl options the C++11 (atomic) supported is equal to "no" and the compilation fails.
This error occurs if OpenSSL is not found during the build process.
Make sure to install the latest version of OpenSSL (Win64 OpenSSL v1.0.1j)
When compiling add the home path of OpenSSL with --extrapath
Example build command:
scons --ssl --release --64 --extrapath=<OPENSSL-HOME> core
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"