I'm trying to add an br2-external package to a Buildroot build for a sama5d4_xplained board. I'm testing it using the utils/test-pkg utility and with every toolchain it fails on BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y, according to the missing.config file. It's an entry in the sama5d4_xplained_defconfig, which is used in the build.
I attempted to find what does the option mean in the manual and by googling, but any information is nowhere to be found. It doesn't seem to be related to the version of kernel headers installed on my machine, since my headers are 4.15.
The exact command used is:
./utils/test-pkg -c ../../config/sama5d4_xplained_defconfig -p {package}
The sama5d4_xplained_defconfig has the problematic entry:
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
logfile content:
#
# configuration written to /home/bartlomiej/br-test-pkg/br-arm-full-static/.config
#
Value requested for BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9 not in final .config
Requested value: BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
Actual value:
Using support/config-fragments/autobuild/br-arm-full-static.config as base
Merging support/config-fragments/minimal.config
Merging ../../config/sama5d4_xplained_defconfig
GEN /home/bartlomiej/br-test-pkg/br-arm-full-static/Makefile
#
# configuration written to /home/bartlomiej/br-test-pkg/br-arm-full-static/.config
#
Value requested for BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9 not in final .config
Requested value: BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
Actual value:
Using support/config-fragments/autobuild/br-arm-full-static.config as base
Merging support/config-fragments/minimal.config
Merging ../../config/sama5d4_xplained_defconfig
GEN /home/bartlomiej/br-test-pkg/br-arm-full-static/Makefile
#
# configuration written to /home/bartlomiej/br-test-pkg/br-arm-full-static/.config
#
Value requested for BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9 not in final .config
Requested value: BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
Actual value:
What does this entry mean, and what do I do to fix the build problems?
You have to make a configuration file that enables just your package. With recent Buildroot, you can also use test-pkg -p <pkg> without -c option.
test-pkg will do a build-test of one or more packages with a collection of different toolchains (by default, a subset of the toolchains used for the autobuilders). The configuration file you supply with -c is supposed to select the package(s) that you want to test. Any toolchain that does not satisfy the dependencies of those packages will be skipped.
The board defconfigs (like sama5d4_xplained_defconfig) build a toolchain as part of their configuration. This toolchain always differs from the toolchains used in the autobuilders. Therefore, if you supply one of the defconfigs as the -c option, all toolchains will always be skipped.
However, if you are only interested in the sama5d4 Xplained board, there is no real need to use test-pkg to test your package with all toolchains. Just enable the package to a custom configuration.
Related
I'm specifying the -Cpanic=abort and -Zbuild-std=panic_abort when compiling. Why does the linker still say it needs libunwind to compile a program?
I'm experimenting with various ways to cross-compile Rust programs as small as possible (using the min-sized-rust repo as a reference). Right now I'm trying to compile the powerpc64-unknown-linux-musl target and I'm stuck on trying to remove a dependency on libunwind.
Here's my setup:
# 1. Install the Rust std source code
rustup component add rust-src --toolchain nightly
# 2. Setup a simple rust repo
cargo init testing
cd testing
# 3. Download a musl toolchain
wget https://musl.cc/powerpc64-linux-musl-cross.tgz
tar xzf powerpc64-linux-musl-cross.tgz
# 4. Try to compile the project (options on the command line instead of in files for
# maximum obviousness).
# RUSTFLAGS:
# -Cpanic=abort - abort immediately on panic
# -Clink-self-contained=no - don't use rustc's builtin libraries and objects (this
# is needed because powerpc64-unknown-linux-musl is a tier 3 target)
# -Clink-arg=--sysroot and -Clink-arg=/path/to/sysroot - pass the option to the linker
# to specify the sysroot of cross-compilation toolchain
# Cargo options:
# --config target.<triple>.linker - specify the linker to use
# -Zbuild-std=std,panic_abort - build the standard library from source. Specify
# panic_abort to make the abort on panic work
RUSTFLAGS="-Cpanic=abort -Clink-self-contained=no -Clink-arg=--sysroot -Clink-arg=powerpc64-linux-musl-cross/powerpc64-linux-musl/" \
cargo +nightly build \
--config "target.powerpc64-unknown-linux-musl.linker=\"powerpc64-linux-musl-cross/bin/powerpc64-linux-musl-gcc\"" \
--target powerpc64-unknown-linux-musl -Zbuild-std=panic_abort,std --release
This fails with the following error:
error: linking with `/home/user/Projects/testing/powerpc64-linux-musl-cross/bin/powerpc64-linux-musl-gcc` failed: exit status: 1
<output snipped>
= note: /home/user/Projects/testing/powerpc64-linux-musl-cross/bin/../lib/gcc/powerpc64-linux-musl/11.2.1/../../../../powerpc64-linux-musl/bin/ld: cannot find -lunwind
From min-size-rust repository:
"Even if panic = "abort" is specified in Cargo.toml, rustc will still include panic strings and formatting code in final binary by default. An unstable panic_immediate_abort feature has been merged into the nightly rustc compiler to address this.
To use this, repeat the instructions above to use build-std, but also pass the following -Z build-std-features=panic_immediate_abort option."
Still, you will get "cannot find -lunwind", because the linker still uses libunwind, even though it's truly unneeded,why! I do not know, maybe it's a bug.(Maybe someone with fair knowledge about linkers can easily solve that.I tried a naive solution which is "cargo .... --verbose", copy , remove "libunwind" then relinking which failed)
I verified that is indeed the missing piece by build from source(--target=x86_64-unknown-linux-musl) AND using an old simple trick which is "touch libunwind.a" in the "self-contained" directory inside a target lib folder.(because the linker would still use it even though it's now truly unneeded, then I gave him a dummy libunwind.a)
In your case, I really tried to build it to your target until I got a headache, but couldn't and stopped, but here is possible solutions:
Giving that you're using "-Z build-std-features=panic_immediate_abort"
-If you can custom the linking process, then solve it (until what seems to be a bug is solved)
-Create a dummy(empty) libunwind.a where it should be in your toolchain
I'm trying to automate some stage of compile/build on Linux RHEL7 host using a bash script, but when i try to use ./configure it fails due to :
configure:3793: error: in `/app/compiling/BUILD_AREA/TEST/SRC/zabbix-4.2.6':
configure:3795: error: cannot compute suffix of object files: cannot compile
using :
CC="gcc"
PATH="/app/app_lib/mysql/bin:/app/app_lib/bin:/app/app_lib/build-1:/app/app_lib:$PATH"
LD_LIBRARY_PATH="/app/app_lib:/app/app_lib/include:/app/app_lib/lib:/app/apache/modules:/app/app_lib/ssl:/app/app_lib/lib/iconv:/app/oracle/product/12.1.0/lib:/app/ap_lib/mysql/lib:$LD_LIBRARY_PATH"
export CC
export PATH
export LD_LIBRARY_PATH
ARG_ZABBIX="--prefix=/app/zabbix --datarootdir=/app/zabbix/share --docdir=/app/zabbix/share/doc/$PKGAPPDIR --enable-agent --enable-ipv6 --enable-java --enable-server --includedir=/app/zabbix/include --libdir=/app/zabbix/lib --mandir=/app/zabbix/share/man/$PKGAPPDIR --with-libcurl=/app/app_lib/bin/curl-config --with-libxml2=/app/app_lib/bin/xml2-config --with-mysql=/app/mysql/bin/mysql_config --with-net-snmp=/app/app_lib/bin/net-snmp-config --with-openipmi=/app/app_lib --with-ssh2=/app/app_lib"
CONFIGURE="configure"
cd /app/compiling/BUILD_AREA/TEST/SRC/zabbix-4.2.6
"./${CONFIGURE}" "${ARG_ZABBIX}" 2>&1
Any help would be really appreciated!
Any help would be really appreciated!
Find the respective config.log (like the one in $(builddir)/gcc) and have a look. Some configure tests might fail as configure is querying availability of host features; the relevant fail is usually recorded at the end of the relevant config.log.
A common cause for this error is that the target Binutils (as, the assembler) cannot be found as configure is trying to find out what suffix to use for object files. Or host as is used where actually the target as (as of --target=) should be used, and the host as throws a syntax error because it is fed with target assembly.
./configure
GCC does not support configuring in the source directory or any of its sub-folders:
"First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree."
I'm trying to learn a bit of Android development.
I've started a new project for a simple hello world and it works fine.
The project is essentially the default one + one more header file in the cpp folder,
However I can't see such .cpp in the project mode, can anyone suggest how to fix this?
(See picture below).
I've attempted to change some setting in File > Project Structure but it doesn't seem to make any difference.
Maybe worth noticing that the header file isn't listed in the CMakeLists.txt at all.
# For more information about using CMake with Android Studio, read the
# documentation: https://d.android.com/studio/projects/add-native-code.html
# Sets the minimum version of CMake required to build the native library.
cmake_minimum_required(VERSION 3.4.1)
# Creates and names a library, sets it as either STATIC
# or SHARED, and provides the relative paths to its source code.
# You can define multiple libraries, and CMake builds them for you.
# Gradle automatically packages shared libraries with your APK.
add_library( # Sets the name of the library.
native-lib
# Sets the library as a shared library.
SHARED
# Provides a relative path to your source file(s).
src/main/cpp/native-lib.cpp )
# Searches for a specified prebuilt library and stores the path as a
# variable. Because CMake includes system libraries in the search path by
# default, you only need to specify the name of the public NDK library
# you want to add. CMake verifies that the library exists before
# completing its build.
find_library( # Sets the name of the path variable.
log-lib
# Specifies the name of the NDK library that
# you want CMake to locate.
log )
# Specifies libraries CMake should link to your target library. You
# can link multiple libraries, such as libraries you define in this
# build script, prebuilt third-party libraries, or system libraries.
target_link_libraries( # Specifies the target library.
native-lib
# Links the target library to the log library
# included in the NDK.
${log-lib} )
According to the android doc:
Known Issue: Android Studio currently shows you only the header files that have matching source files—even if you specify other headers in your CMake build script. See Issue #38068472
This means you need a pair filename.h and filename.cpp, you modify your CMakeLists.txt accordingly. The header file will be shown in project mode if it has a corresponding .cpp with the same name.
Reference:
https://developer.android.com/studio/projects/add-native-code
I guess this would be a generic question on including libraries with existing makefiles within cmake; but here's my context -
I'm trying to include scintilla in another CMake project, and I have the following problem:
On Linux, scintilla has a makefile in (say) the ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk directory; if you run make in that directory (as usual), you get a ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/bin/scintilla.a file - which (I guess) is the static library.
Now, if I'd try to use cmake's ADD_LIBRARY, I'd have to manually specify the sources of scintilla within cmake - and I'd rather not mess with that, given I already have a makefile. So, I'd rather call the usual scintilla make - and then instruct CMAKE to somehow refer to the resulting scintilla.a. (I guess that this then would not ensure cross-platform compatibility - but note that currently cross-platform is not an issue for me; I'd just like to build scintilla as part of this project that already uses cmake, only within Linux)
So, I've tried a bit with this:
ADD_CUSTOM_COMMAND(
OUTPUT scintilla.a
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... but then, add_custom_command adds a "target with no output"; so I'm trying several approach to build upon that, all of which fail (errors given as comment):
ADD_CUSTOM_TARGET(scintilla STATIC DEPENDS scintilla.a) # Target "scintilla" of type UTILITY may not be linked into another target.
ADD_LIBRARY(scintilla STATIC DEPENDS scintilla.a) # Cannot find source file "DEPENDS".
ADD_LIBRARY(scintilla STATIC) # You have called ADD_LIBRARY for library scintilla without any source files.
ADD_DEPENDENCIES(scintilla scintilla.a)
I'm obviously quote a noob with cmake - so, is it possible at all to have cmake run a pre-existing makefile, and "capture" its output library file, such that other components of the cmake project can link against it?
Many thanks for any answers,
Cheers!
EDIT: possible duplicate: CMake: how do i depend on output from a custom target? - Stack Overflow - however, here the breakage seems to be due to the need to specifically have a library that the rest of the cmake project would recognize...
Another related: cmake - adding a custom command with the file name as a target - Stack Overflow; however, it specifically builds an executable from source files (which I wanted to avoid)..
You could also use imported targets and a custom target like this:
# set the output destination
set(SCINTILLA_LIBRARY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk/scintilla.a)
# create a custom target called build_scintilla that is part of ALL
# and will run each time you type make
add_custom_target(build_scintilla ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target")
# now create an imported static target
add_library(scintilla STATIC IMPORTED)
# Import target "scintilla" for configuration ""
set_property(TARGET scintilla APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
set_target_properties(scintilla PROPERTIES
IMPORTED_LOCATION_NOCONFIG "${SCINTILLA_LIBRARY}")
# now you can use scintilla as if it were a regular cmake built target in your project
add_dependencies(scintilla build_scintilla)
add_executable(foo foo.c)
target_link_libraries(foo scintilla)
# note, this will only work on linux/unix platforms, also it does building
# in the source tree which is also sort of bad style and keeps out of source
# builds from working.
OK, I think I have it somewhat; basically, in the CMakeLists.txt that build scintilla, I used this only:
ADD_CUSTOM_TARGET(
scintilla.a ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... and then, the slightly more complicated part, was to find the correct cmake file elsewhere in the project, where the ${PROJECT_NAME} was defined - so as to add a dependency:
ADD_DEPENDENCIES(${PROJECT_NAME} scintilla.a)
... and finally, the library needs to be linked.
Note that in the commands heretofore, the scintilla.a is merely a name/label/identifier/string (so it could be anything else, like scintilla--a or something); but for linking - the full path to the actual `scintilla.a file is needed (which in this project ends up in a variable ${SCINTILLA_LIBRARY}). In this project, the linking basically occurs through a form of a
list(APPEND PROJ_LIBRARIES ${SCINTILLA_LIBRARY} )
... and I don't really know how cmake handles the actual linking afterwards (but it seems to work)
For consistency, I tried to use ${SCINTILLA_LIBRARY} instead of scintilla.a as identifier in the ADD_CUSTOM_TARGET, but got error: "Target names may not contain a slash. Use ADD_CUSTOM_COMMAND to generate files". So probably this could be solved smarter/more correct with ADD_CUSTOM_COMMAND - however, I read that it "defines a new command that can be executed during the build process. The outputs named should be listed as source files in the target for which they are to be generated."... And by now I'm totally confused so as to what is a file, what is a label, and what is a target - so I think I'll leave at this (and not fix it if it ain't broken :) )
Well, it'd still be nice to know a more correct way to do this eventually,
Cheers!
I am using CMake to build a program on linux. The program compiles successfully and runs from the project build directory. The program is linked with a custom library in the directory ${HOME}/build/lib
I have an install stage with:
install(TARGETS ProgName RUNTIME DESTINATION bin)
When I run make install the program gets put in the correct place, but the cmake installer removes the runtime path from the binary.
-- Install configuration: "Debug"
-- Installing: *binary name*
-- Removed runtime path from "*binary name*"
I have read articles on the internet discussing the misuse of the LD_LIBRARY_PATH variable so I like to keep mine limited to system library locations if possible. I am not sysadmin so I cannot add the location to the default linker search path either.
Does anyone know how I can keep the development-time linking paths when installing or at least customising which paths are added to the runtime?
Cheers
Note: if you don't want to modify the cmake scripts themselves, setting property around, you can launch you cmake with a directive asking to not remove the runtime path:
See "Variables that Control the Build", with variable: "CMAKE_SKIP_RPATH"
If true, do not add run time path information.
If this is set to TRUE, then the rpath information is not added to compiled executables.
The default is to add rpath information if the platform supports it. This allows for easy running from the build tree.
To omit RPATH in the install step, but not the build step, use CMAKE_SKIP_INSTALL_RPATH instead.
If the deliveries already contained the right runtime path, that directive will avoid cmake to do any modification to the current runtime path included in said deliveries.
cmake -DCMAKE_SKIP_RPATH=ON xxx.cmake
You should look at set_target_properties command and the property BUILD_WITH_INSTALL_RPATH
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_target_properties
This works for CMake 2.8
set_target_properties(foo PROPERTIES INSTALL_RPATH_USE_LINK_PATH TRUE)
where foo is the target you defined earlier:
project(foo)
add_executable(foo ...)
...
install(TARGETS foo DESTINATION bin)
...
Before
% sudo make install
Install the project...
-- Install configuration: ""
-- Installing: /opt/mystuff/bin/foo
-- Removed runtime path from "/opt/mystuff/bin/foo"
After
% sudo make install
Install the project...
-- Install configuration: ""
-- Installing: /opt/mystuff/bin/foo
-- Set runtime path of "/opt/mystuff/bin/foo" to "/opt/zzyzx/lib:/opt/bar/lib/x86_64"