Buildroot error when building with Ubuntu 21.10 - linux-kernel

I am trying to compile linux for RISCV Arch using buildroot(busybox). I was using 18.04 and 20.04 previously and had no issues compiling it. Right now, I have upgraded it to 21.10 for building some other stuffs. I have moved my toolchain and I can find it using the which command. When I try to compile linux I get some error which I havn't faced in the earlier versions.
>>> host-m4 1.4.18 Building
In file included from /usr/include/signal.h:328,
from ./signal.h:52,
from c-stack.c:49:
c-stack.c:55:26: error: missing binary operator before token "("
55 | #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
| ^~~~~~~~
CC closein.o
c-stack.c:134:8: error: variably modified 'buffer' at file scope
134 | char buffer[SIGSTKSZ];
| ^~~~~~
CC closeout.o
I am confused on how different versions can cause this error.
Thanks in advance.

It looks like you have hit a change in GNU C Library version 2.34 that can make SIGSTKSZ non-constant.
From the GNU C Library 2.34 release announcement:
Add _SC_MINSIGSTKSZ and _SC_SIGSTKSZ. When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are no longer constant on Linux. MINSIGSTKSZ is redefined to sysconf(_SC_MINSIGSTKSZ) and SIGSTKSZ is redefined to sysconf (_SC_SIGSTKSZ). This supports dynamic sized register sets for modern architectural features like Arm SVE.
A possible workaround is to configure buildroot to build host-m4 version 1.4.19 instead of 1.4.18, because it no longer uses SIGSTKSZ.

I saw that error when building on Ubuntu 22.04 for an embedded Linux board using Buildroot. It got stuck when building the host-m4 package. #Ian Abbott is right:
A possible workaround is to configure buildroot to build host-m4 version 1.4.19 instead of 1.4.18, because it no longer uses SIGSTKSZ.
In Buildroot, to update from m4 v 1.4.18 to 1.4.19, simply grab the latest files here: https://github.com/buildroot/buildroot/tree/master/package/m4
As of right now (9 Jan. 2023), the upstream Buildroot m4 version there is
1.4.19, as shown here: https://github.com/buildroot/buildroot/blob/master/package/m4/m4.mk#L7:
################################################################################
#
# m4
#
################################################################################
M4_VERSION = 1.4.19
M4_SOURCE = m4-$(M4_VERSION).tar.xz
M4_SITE = $(BR2_GNU_MIRROR)/m4
M4_LICENSE = GPL-3.0+
M4_LICENSE_FILES = COPYING
$(eval $(host-autotools-package))
How to upgrade/update any buildroot package to the latest upstream version, from the command-line
Here is an example of how to upgrade any buildroot package from the command-line. In these commands, I am upgrading the m4 package, to solve the problem in the OP's question. Change the word m4 in all 3 places to the name of the package you'd like to update:
# initially:
cd path/to/buildroot
git remote add upstream https://github.com/buildroot/buildroot.git
git fetch upstream master
# then (from within the "buildroot" repo or subrepo)
rm -r package/m4
git checkout upstream/master -- package/m4
git add -A
git status
git commit -m "Update m4 library"

Related

How to compile BCC on Ubuntu 20.04?

I am trying to compile the BCC BPF framework (https://github.com/iovisor/bcc) on Ubuntu 20.04. I followed all the instructions for 18.04, but of course; they fail.
The issue i have seems to be clang-related though
In file included from /usr/local/include/clang/Frontend/CompilerInstance.h:15,
from /home/matt/code/bpf/bcc/src/cc/frontends/clang/loader.cc:43:
/usr/local/include/clang/Frontend/CompilerInvocation.h:157:15: note: candidate: ‘static bool clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, llvm::ArrayRef<const char*>, clang::DiagnosticsEngine&)’
157 | static bool CreateFromArgs(CompilerInvocation &Res,
| ^~~~~~~~~~~~~~
/usr/local/include/clang/Frontend/CompilerInvocation.h:157:15: note: candidate expects 3 arguments, 4 provided
make[2]: *** [src/cc/frontends/clang/CMakeFiles/clang_frontend.dir/build.make:63: src/cc/frontends/clang/CMakeFiles/clang_frontend.dir/loader.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:982: src/cc/frontends/clang/CMakeFiles/clang_frontend.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
How do i get BCC compiling on Ubuntu 20.04 ?
As of BCC v0.14.0-a28337a, I have to use llvm-7 instead of the latest LLVM. Also, -DPYTHON_CMD=python3 or installing Python2 (or python command) is required because Python2 is no longer installed by default. Other dependencies listed in https://github.com/iovisor/bcc/blob/master/INSTALL.md#ubuntu---source are also required.
I can build it on my Ubuntu 20.04 VM.
cmake -Bbuild -DPYTHON_CMD=python3 -DCMAKE_PREFIX_PATH=/usr/lib/llvm-7
make -Cbuild -j$(nproc)
I had the same problem. What worked for me was use a different branch, actually the latest tag, you can check that at github site for the project: https://github.com/iovisor/bcc.git
One I did a git checkout v0.24.0 # for example it worked.
Hint:
Probably the main branch may not be the best choice as it may be broken due to the latest commit, changing for the last stable release has already worked for me on many other different projects.

Installing gcc on s390x

I need a C compiler on my s390, which runs RHEL 7.6. When I do "yum list | grep gcc", I have the following:
libgcc.s390x 4.8.5-36.el7
compat-gcc-44.s390x 4.4.7-8.el7
compat-gcc-44-c++.s390x 4.4.7-8.el7
gcc.s390x 4.8.5-16.el7
gcc-c++.s390x 4.8.5-16.el7
gcc-gfortran.s390x 4.8.5-16.el7
gcc-objc.s390x 4.8.5-16.el7
gcc-objc++.s390x 4.8.5-16.el7
libgcc.s390 4.8.5-16.el7
I then do: yum install gcc.s390x and I obtain the following error:
Error: Package: glibc-2.17-196.el7.s390
Requires: glibc-common = 2.17-196.el7
Installed: glibc-common-2.17-260.el7_6.3.s390x (#rhel-7-for-system-z-rpms)
glibc-common = 2.17-260.el7_6.3
Available: glibc-common-2.17-196.el7.s390x
glibc-common = 2.17-196.el7
What I read from this is that s390x package is installed but the one needed is the one that does not have the s390 extension.
How can I get around this ? I pulling gcc directly from git but when I do a configure the message says that a compiler needs to be installed.
Any help would be much appreciated. Thanks - C
This output line
Available: glibc-common-2.17-196.el7.s390x
shows that the configured repositories only contain glibc versions up to RHSA-2017:1916. This means that you have configured repositories for Red Hat Enterprise Linux 7.4 (and not even Extended Update Support). However, someone at one point upgraded glibc to a package version from Red Hat Enterprise Linux 7.6.
Installing GCC needs additional glibc components, and these have to match the already-installed version. Since the 7.6 packages are not available from the configured repositories, installation fails with a dependency error.
If you need assistance with subscription management, you should file a support ticket.

What should I override in cargo for the openssl-rust crate to build? [duplicate]

I tried to install the Iron framework for Rust on Mac OS X 10.11.2, but it failed when I run cargo build or cargo run on compiling openssl's stuff:
failed to run custom build command for `openssl-sys-extras v0.7.4`
Process didn't exit successfully: `/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-apple-darwin")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-apple-darwin")
debug=true opt-level=0
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CC_x86_64-apple-darwin = None
CC_x86_64_apple_darwin = None
HOST_CC = None
CC = None
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CFLAGS_x86_64-apple-darwin = None
CFLAGS_x86_64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = None
running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-o" "/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/out/src/openssl_shim.o" "-c" "src/openssl_shim.c"
ExitStatus(Code(1))
command did not execute successfully, got: exit code: 1
--- stderr
src/openssl_shim.c:1:10: fatal error: 'openssl/hmac.h' file not found
#include <openssl/hmac.h>
^
1 error generated.
thread '<main>' panicked at 'explicit panic', /xxx/.cargo/registry/src/github.com-0a35038f75765ae4/gcc-0.3.21/src/lib.rs:772
openssl version seems OK:
$ openssl version
OpenSSL 0.9.8zg 14 July 2015
I don't know what I have to do in order to make this installation work and give Iron a try.
As of rust-openssl version 0.8, Homebrew-installed OpenSSL libraries will be automatically detected by the crate, there is no need to set extra environment variables.
If you need to support a version prior to that or choose to not use Homebrew, read on.
This is a known issue (also this and this), but not one that the crate can fix.
The quick solution is to install OpenSSL with Homebrew and then explicitly point to the directories where OpenSSL is found by setting the OPENSSL_INCLUDE_DIR and OPENSSL_LIB_DIR environment variables:
OPENSSL_INCLUDE_DIR=/usr/local/Cellar/openssl/1.0.2e/include \
OPENSSL_LIB_DIR=/usr/local/Cellar/openssl/1.0.2e/lib \
cargo build
If you've already done one cargo build, you will need to run cargo clean first to clear our some stale cached information.
If you don't want to set this for every shell you open, add it to your shell initialization files (like ~/.bash_profile). You can make it a bit less brittle by not hard-coding the version number:
export OPENSSL_INCLUDE_DIR=$(brew --prefix openssl)/include
export OPENSSL_LIB_DIR=$(brew --prefix openssl)/lib
If you don't want to use Homebrew, follow the same process but using the appropriate path to your copy of OpenSSL.
The longer reason is well described by andrewtj:
OpenSSL doesn't have a stable ABI so for compatibility purposes Apple have maintained a fork that's compatible with one of the earlier ABIs. They deprecated OpenSSL in 10.7 and finally dropped the headers in 10.11 to push OS X app developers toward bundling their own OpenSSL or using their frameworks. The dylibs have been left around so apps that haven't been updated don't break. You can still link against them but you're opening yourself up to odd compatibility issues by doing so (unless you grab the headers from an earlier OS X release).
With Brew use like this:
brew install openssl
export OPENSSL_INCLUDE_DIR=`brew --prefix openssl`/include
export OPENSSL_LIB_DIR=`brew --prefix openssl`/lib
cargo clean
cargo build
If you have homebrew's openssl installed just add the following to your Cargo.toml:
[target.x86_64-apple-darwin.openssl-sys]
rustc-link-search = [ "/usr/local/opt/openssl/lib" ]
rustc-link-lib = [ "ssl", "crypto" ]
include = [ "/usr/local/opt/openssl/include" ]
and then cargo clean && cargo build. No breaking OS X by introducing an incompatible openssl into the library load paths, and no forgetting to set/unset environment variables when you want to build (or polluting your shell env when not working on Rust stuff). All in all a much happier and less infuriating approach.
I can't add this answer to my own question where it belongs (because it depends on homebrew), because Shepmaster decided it should be closed but I'll answer here and link to that question.
https://stackoverflow.com/a/39380733/1317564's answer for MacPorts:
sudo port install openssl
export OPENSSL_INCLUDE_DIR=/opt/local/include
export OPENSSL_LIB_DIR=/opt/local/lib
cargo clean
cargo build

OpenSSL crate fails compilation on Mac OS X 10.11

I tried to install the Iron framework for Rust on Mac OS X 10.11.2, but it failed when I run cargo build or cargo run on compiling openssl's stuff:
failed to run custom build command for `openssl-sys-extras v0.7.4`
Process didn't exit successfully: `/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-apple-darwin")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-apple-darwin")
debug=true opt-level=0
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CC_x86_64-apple-darwin = None
CC_x86_64_apple_darwin = None
HOST_CC = None
CC = None
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CFLAGS_x86_64-apple-darwin = None
CFLAGS_x86_64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = None
running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-o" "/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/out/src/openssl_shim.o" "-c" "src/openssl_shim.c"
ExitStatus(Code(1))
command did not execute successfully, got: exit code: 1
--- stderr
src/openssl_shim.c:1:10: fatal error: 'openssl/hmac.h' file not found
#include <openssl/hmac.h>
^
1 error generated.
thread '<main>' panicked at 'explicit panic', /xxx/.cargo/registry/src/github.com-0a35038f75765ae4/gcc-0.3.21/src/lib.rs:772
openssl version seems OK:
$ openssl version
OpenSSL 0.9.8zg 14 July 2015
I don't know what I have to do in order to make this installation work and give Iron a try.
As of rust-openssl version 0.8, Homebrew-installed OpenSSL libraries will be automatically detected by the crate, there is no need to set extra environment variables.
If you need to support a version prior to that or choose to not use Homebrew, read on.
This is a known issue (also this and this), but not one that the crate can fix.
The quick solution is to install OpenSSL with Homebrew and then explicitly point to the directories where OpenSSL is found by setting the OPENSSL_INCLUDE_DIR and OPENSSL_LIB_DIR environment variables:
OPENSSL_INCLUDE_DIR=/usr/local/Cellar/openssl/1.0.2e/include \
OPENSSL_LIB_DIR=/usr/local/Cellar/openssl/1.0.2e/lib \
cargo build
If you've already done one cargo build, you will need to run cargo clean first to clear our some stale cached information.
If you don't want to set this for every shell you open, add it to your shell initialization files (like ~/.bash_profile). You can make it a bit less brittle by not hard-coding the version number:
export OPENSSL_INCLUDE_DIR=$(brew --prefix openssl)/include
export OPENSSL_LIB_DIR=$(brew --prefix openssl)/lib
If you don't want to use Homebrew, follow the same process but using the appropriate path to your copy of OpenSSL.
The longer reason is well described by andrewtj:
OpenSSL doesn't have a stable ABI so for compatibility purposes Apple have maintained a fork that's compatible with one of the earlier ABIs. They deprecated OpenSSL in 10.7 and finally dropped the headers in 10.11 to push OS X app developers toward bundling their own OpenSSL or using their frameworks. The dylibs have been left around so apps that haven't been updated don't break. You can still link against them but you're opening yourself up to odd compatibility issues by doing so (unless you grab the headers from an earlier OS X release).
With Brew use like this:
brew install openssl
export OPENSSL_INCLUDE_DIR=`brew --prefix openssl`/include
export OPENSSL_LIB_DIR=`brew --prefix openssl`/lib
cargo clean
cargo build
If you have homebrew's openssl installed just add the following to your Cargo.toml:
[target.x86_64-apple-darwin.openssl-sys]
rustc-link-search = [ "/usr/local/opt/openssl/lib" ]
rustc-link-lib = [ "ssl", "crypto" ]
include = [ "/usr/local/opt/openssl/include" ]
and then cargo clean && cargo build. No breaking OS X by introducing an incompatible openssl into the library load paths, and no forgetting to set/unset environment variables when you want to build (or polluting your shell env when not working on Rust stuff). All in all a much happier and less infuriating approach.
I can't add this answer to my own question where it belongs (because it depends on homebrew), because Shepmaster decided it should be closed but I'll answer here and link to that question.
https://stackoverflow.com/a/39380733/1317564's answer for MacPorts:
sudo port install openssl
export OPENSSL_INCLUDE_DIR=/opt/local/include
export OPENSSL_LIB_DIR=/opt/local/lib
cargo clean
cargo build

Webkit not found on OSX

I'm trying to compile mu that uses the headers webkit/webkitwebview.h and webkit/webkitwebresource.h. The OSX version of webkit framework located in /System/Library/Frameworks doesn't seem to have it, the headers are different and use NS data types and stuff.
So I downloaded webkit-gtk with MacPorts (since it's not available through Homebrew) and pointed $PKG_CONFIG_PATH to webkit-1.0.pc. I verified and this version has the needed headers.
But the problem is, I still get an error, the configure file doesn't seem to be able to find it.
checking for WEBKIT... no
I don't even know, actually, if webkit-1.0.pc is the package config it is looking for.
I had two other compilation problems prior to this, with glib.h and gtk.h but managed to go through. This is the last issue I need to resolve to have a fully functional email client in Emacs.
Help!
this worked for me [1]:
add this to ~/.profile (or wherever you take care of this stuff):
# ~/.profile stuff
export PKG_CONFIG_PATH="/opt/local/lib/pkgconfig/:$PKG_CONFIG_PATH"
then source:
$ source ~/.profile
then (assuming you're in the mu dir) voila [2]:
$ ./configure
[1] i have gtk installed via homebrew, installed webkit-gtk3 via macports, and cloned mu from the github repo. running os x 10.9.5
[2] here's the $ ./configure output:
mu configuration is complete.
------------------------------------------------
mu version : 0.9.10
Xapian version : 1.2.19
GLib version : 2.42.1
GMime version : 2.6.20
GTK+ version : 3.14.5
Webkit version : 2.4.7
Emacs version : GNU Emacs 24.4.51.1
Have wordexp : yes
Build mu4e emacs frontend : yes
Build 'mug' toy-ui (gtk+/webkit) : yes
McCabe's Cyclomatic Complexity tool : no
Have direntry->d_ino : yes
Have direntry->d_type : yes
------------------------------------------------

Resources