Buildroot provide a way to add sqlite to my build configuration but I can't see anywhere that it indicates if the sqlite libs have multi-thread support. How can I tell if the version of the sqlite library included by Builtroot has multi-thread support.
Thanks.
Buildroot's sqlite.mk file contains the following fragment:
ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
SQLITE_CONF_OPTS += --enable-threadsafe
else
SQLITE_CONF_OPTS += --disable-threadsafe
SQLITE_CFLAGS += -DSQLITE_THREADSAFE=0
endif
In other words, if threads are supported, sqlite is built threadsafe.
Related
Hopefully this will be a simple question to answer: I am trying to add a package to buildroot that requires the kernel BPF syscall feature to be enabled.
If the feature is enabled, everything works fine, if not, the build fails with a marginally unhelpful error. What i would like to do is perform a quick check in the .mk file to see if the feature is present and print out a slightly more user-friendly error if it is not.
I tried adding:
ifneq ($(CONFIG_BPF_SYSCALL),y)
$(error Kernel feature CONFIG_BPF_SYSCALL is required)
endif
But this always seems to trigger as i assume CONFIG_BPF_SYSCALL does not exist in the package build scope. Is there a simple way to access to the kernel config list from a package build env?
Many thanks
It works the other way around: it is the "linux" package in Buildroot that ensures it enables the right options when a given package is enabled and requires some specific kernel features. See linux/linux.mk, which contains things like that:
$(if $(BR2_PACKAGE_KTAP),
$(call KCONFIG_ENABLE_OPT,CONFIG_DEBUG_FS,$(#D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_ENABLE_DEFAULT_TRACERS,$(#D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_PERF_EVENTS,$(#D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_FUNCTION_TRACER,$(#D)/.config))
This ensures that CONFIG_DEBUG_FS, CONFIG_ENABLE_DEFAULT_TRACERS, CONFIG_PERF_EVENTS and CONFIG_FUNCTION_TRACER are enabled in the kernel configuration when the ktap Buildroot is enabled.
Note that this mechanism may be changed in the near future in Buildroot, see the patch series at http://patchwork.ozlabs.org/project/buildroot/list/?series=168565.
I am trying to build a custom distribution for an embedded device. I need the 'stat'-command (which is part of GNU coreutils) to support long-options, e.g. stat --printf.
The stat-version the build currently includes is ancient and does not support long-options.
root#target:/# stat -v
stat version 3.0
The receipe for stat is located at sources/poky/meta/recipes-extended/stat_3.3.bb which points to http://www.ibiblio.org/pub/Linux/utils/file/stat-3.3.tar.gz as its SRC_URI.
The coreutils receipe is located at sources/poky/meta/recipes-core/coreutils/coreutils_8.27.bb which points to https://ftp.gnu.org/gnu/coreutils/coreutils-8.27.tar.xz as its SRC_URI.
How I understand it, bitbake uses ALTERNATIVE_PRIORITY[stat] which is defined in both recipes to decide which version is to be included. Since the coreutils_8.27 should be new enough, I tried to simply delete the stat_3.3-receipe. This didn't work, the old 3.3 version of stat is still included.
What would be the best way to include a newer version or coreutils (or stat) which supports long-options?
To fix this I had to include the 'coreutils'-package (IMAGE_INSTALL_append += " coreutils") in my local.conf and raise the ALTERNATIVE_PRIORITY for the coreutils-package.
I'm trying to build a toolchain for my hobby kernel, but I'm running into problems when building Newlib. Whenever I try to run autoreconf in my kernels directory under newlib/libc/sys/ I get an error:
configure.in:5: error: support for Cygnus-style trees has been removed
Here is the content of configure.in (basically, taken from the below tutorial):
AC_PREREQ(2.59)
AC_INIT([newlib], [NEWLIB_VERSION])
AC_CONFIG_SRCDIR([crt0.S])
AC_CONFIG_AUX_DIR(../../../..)
NEWLIB_CONFIGURE(../../..)
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
and the source for Makefile.am (again mostly from tutorial):
AUTOMAKE_OPTIONS = cygnus
INCLUDES = $(NEWLIB_CFLAGS) $(CROSS_CFLAGS) $(TARGET_CFLAGS)
AM_CCASFLAGS = $(INCLUDES)
noinst_LIBRARIES = lib.a
if MAY_SUPPLY_SYSCALLS
extra_objs = $(lpfx)syscalls.o
else
extra_objs =
endif
lib_a_SOURCES =
lib_a_LIBADD = $(extra_objs)
EXTRA_lib_a_SOURCES = syscalls.c crt0.S
lib_a_DEPENDENCIES = $(extra_objs)
lib_a_CCASFLAGS = $(AM_CCASFLAGS)
lib_a_CFLAGS = $(AM_CFLAGS)
if MAY_SUPPLY_SYSCALLS
all: crt0.o
endif
ACLOCAL_AMFLAGS = -I ../../..
CONFIG_STATUS_DEPENDENCIES = $(newlib_basedir)/configure.host
Yes, I have tried removing the AUTOMAKE_OPTIONS=cygnus.
I've Googled around and been trying to understand this, and as far as I can tell, it is because of the version of autotools I'm using. According to the tutorial I used originally (OSDev - OS Specific Toolchain), I need an older version. My problem is that I'm using Kubuntu, which uses the apt package manager, and that version is not available to fall back to even temporarily. There has to be some fix for this. Either Newlib is outdated (this release is from December of 2013...) or the developers are crazy for depending on an outdated autotools version.
The only other thing I can think is that this is a message from the newlib configuration scheme itself in which case I have no idea how to modify my configure.in and Makefile.am to align with the new newlib configure format. That tutorial is the only one I've found that didn't use libgloss (which I'd prefer not to do) so far and the documentation of adding a new target is rather lacking in the documentation for newlib (or I missed something).
Here is some version information:
System: Kubuntu 14.04
Automake: 1.14.1
Autoconf: 2.69
Newlib: 2.1.0
Unfortunately I'm afraid using automake 1.12 or earlier is your only choice. Ubuntu has an Automake1.11 separate package to help you there, if I'm not mistaken, since the compatibility between 1.12 and 1.14 is generally good, but before that it was spotty.
I am writing this answer for people struggling with the tutorial described here.
I am in the same situation you are (or were), I am building a kernel from scratch and I wanted to port newlib to my toolchain. Unfortunately I think the tutorial has become out of date because I followed the instructions EXACTLY, even installing the correct software with the proper versions (including the correct newlib version). The accepted solution above didn't work for me but I found another solution that might work for others:
Step 1 - get the correct software
Acquire Automake (v1.12) and Autoconf (v2.65) from here:
http://ftp.gnu.org/gnu/automake/automake-1.12.tar.gz
http://ftp.gnu.org/gnu/autoconf/autoconf-2.65.tar.gz
Step 2 - build process
Untar both of the archives:
tar xf automake-1.12.tar.gz
tar xf autoconf-2.65.tar.gz
Create a destination folder:
mkdir ~/bin
Create a build folder:
mkdir build
cd build
Configure automake first:
../automake-1.12/configure --prefix="~/bin"
Make and install
make && make install
Now lets configure autoconf
../autoconf-2.65/configure --prefix=~/bin
Then make and install:
make && make install
You should now have the proper binaries in ~/bin!
Step 3 - update PATH
To add these binaries to your path temporarily (recommended):
export PATH=~/bin:$PATH
Once you update your path, rerun autoconf and autoreconf and it should complete.
I have a library (lib.a) and a header file (lib1.h). The problem is the library is too big and only a relatively small subset of users need it.
Would it be possible to build my Xcode project without the library? Currently I get:
ld: library not found for -llib
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Would it be possible to guard against usage of the library not existing inside the Xcode project? I found the following, but I'm not sure if it's sufficient (assuming I can get the project to build without the lib):
if ([MyLibABC class]) { ... } else { NSLog(#"Add Lib.a"); }
Side note:
In Java I would use reflection to call methods implemented in the library (lib.jar) and if the library is not present I would catch the ClassNotFoundException and show an error message or something (lib.jar missing, please consult the documentation).
I'm targeting >= iOS5.
Unlike desktop operating systems which support dynamic libraries, iOS supports only static libraries. The only way around this would be building two targets - one that uses the library, and the other one that does not.
You can build both targets from the same set of sources by using conditional compilation. In the version that conditionally compiles out the references to the "big library" there would be no references to it, so the linker would not complain about missing references.
I want the compiled application to have the commit number, source files checksums and other things to be available during the compilation.
In plain Makefiles I do like this:
prog: VERSION source.c
gcc -DVERSION=\"$(shell cat VERSION)\" source.c -o prog
VERSION: .git
git describe > VERSION
How to use something similar with qmake?
If you were to pass the version information as an included file (let's say "version.h") instead of a #define, then you could add the following to your qmake file
# Define how to create version.h
version.target = version.h
version.commands = <PUT_YOUR_COMMANDS_HERE>
version.depends = .git
QMAKE_EXTRA_TARGETS += version
PRE_TARGETDEPS += version.h
The first 3 lines tell how to make a new target object called "version" that generates "version.h". It is made by executing the commands "<PUT_YOUR_COMMANDS_HERE>". The target is dependent on ".git"
The "QMAKE_EXTRA_TARGETS" says there is a new target known as "version".
The "PRE_TARGETDEPS" indicates that "version.h" needs to exist before anything else can be done (which forces it to be made if it isn't already made).
A simpler solution even if #jwernemy as nice way to solve it:
VERSION = $$system(-git-dir=$PWD/.git <PUT_YOUR_GIT_COMMANDS_HERE>)