Hi I am trying to build QT 5.10.1 with this guide. I am getting this error;
Command line: -opengl es2 -device linux-rasp-pi3-vc4-g++ -device-option
CROSS_COMPILE=arm-linux-gnueabihf- -sysroot /opt/qt5pi/sysroot -prefix
/usr/local/qt5pi -opensource -confirm-license -skip qtwebengine -skip
qtscript -nomake examples -no-use-gold-linker -make libs -v
executing config test architecture
+ cd /home/pi/qt5build/config.tests/arch &&
/home/pi/qt5build/qtbase/bin/qmake "CONFIG -= qt debug_and_release
app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch"
"QMAKE_CFLAGS += --sysroot=/opt/qt5pi/sysroot" "QMAKE_CXXFLAGS += --
sysroot=/opt/qt5pi/sysroot" "QMAKE_LFLAGS += --sysroot=/opt/qt5pi/sysroot" -
early "CONFIG += cross_compile" /home/pi/qt-everywhere-src-
5.10.1/qtbase/config.tests/arch
+ cd /home/pi/qt5build/config.tests/arch && MAKEFLAGS= /usr/bin/make clean
&& MAKEFLAGS= /usr/bin/make
> rm -f arch.o
> rm -f *~ core *.core
> arm-linux-gnueabihf-g++ -c -march=armv8-a -mtune=cortex-a53 -mfpu=crypto-
neon-
fp-armv8 -mfloat-abi=hard --sysroot=/opt/qt5pi/sysroot -O2 -w -fPIC -
I/home/pi/qt-everywhere-src-5.10.1/qtbase/config.tests/arch -I. -
I/home/pi/qt-everywhere-src-5.10.1/qtbase/mkspecs/devices/linux-rasp-
pi3-vc4-g++ -o arch.o /home/pi/qt-everywhere-src-
5.10.1/qtbase/config.tests/arch/arch.cpp
> /home/pi/qt-everywhere-src-5.10.1/qtbase/config.tests/arch/arch.cpp:43:19:
fatal error: stdio.h: No such file or directory
> #include <stdio.h>
> ^
> compilation terminated.
> Makefile:179: recipe for target 'arch.o' failed
> make: *** [arch.o] Error 1
I checked the include file in the /usr location it is there. If I add the file arch.cpp location then it needs another file. How can I fix this?
Thanks for help.
fatal error: stdio.h: No such file or directory
This suggests you are missing build dependencies on your host machine (the machine on which you are running configure), most likely libc
I'm not sure what package manager you have, but with apt you can install this with:
sudo apt install libc6-dev
Failing that, you also might like to try:
sudo apt install build-essential
which installs various compilation tools/libraries.
Related
I am trying to find a way to enable incremental compilation with CMake through a toolchain upgrade. Here is the problematic scenario :
Branch main uses g++-9 (using CMAKE_CXX_COMPILER=g++-9)
A new branch uses g++-10 (using CMAKE_CXX_COMPILER=g++-10)
Commits are happening on both branches
Incremental builds on one branch work fine
Switching to the other branch and explicitly invoking CMake fails
My question is the following : I'm looking for the proper way to make the invocation of CMake succeed and rebuild all the project from scratch when a toolchain change happens.
Here is a script that will make it quick and easy to reproduce the problem. This script requires Docker. It will create folders Sources and Build at the location where it is executed to avoid littering your filesystem. It then creates Dockerfiles to build docker containers with both g++ and cmake. It then creates a dummy Hello World C++ CMake project. Finally, it creates a folder for build artifacts and then executes the build with g++-9 and then g++-10. The second build fails because CMake generates an error.
#!/bin/bash
set -e
mkdir -p Sources
mkdir -p Build
# Creates a script that will be executed inside the docker container to perform builds
cat << EOF > Sources/Compile.sh
cd /Build \
&& cmake /Sources \
&& make \
&& ./IncrementalBuild
EOF
# Creates a Dockerfile that will be used to have both gcc-9 and cmake
cat << EOF > Sources/Dockerfile-gcc9
FROM gcc:9
RUN apt-get update && apt-get install -y cmake
RUN ln -s /usr/local/bin/g++ /usr/local/bin/g++-9
ADD Compile.sh /Compile.sh
RUN chmod +x /Compile.sh
ENTRYPOINT /Compile.sh
EOF
# Creates a Dockerfile that will be used to have both gcc-10 and cmake
cat << EOF > Sources/Dockerfile-gcc10
FROM gcc:10
RUN apt-get update && apt-get install -y cmake
RUN ln -s /usr/local/bin/g++ /usr/local/bin/g++-10
ADD Compile.sh /Compile.sh
RUN chmod +x /Compile.sh
ENTRYPOINT /Compile.sh
EOF
# Creates a dummy C++ program that will be compiled
cat << EOF > Sources/main.cpp
#include <iostream>
int main()
{
std::cout << "Hello World!\n";
}
EOF
# Creates CMakeLists.txt that will be used to compile the dummy C++ program
cat << EOF > Sources/CMakeLists.txt
cmake_minimum_required(VERSION 3.9)
project(IncrementalBuild CXX)
add_executable(IncrementalBuild main.cpp)
set_target_properties(IncrementalBuild PROPERTIES CXX_STANDARD 17)
EOF
# Build the docker images with both Dockerfiles created earlier
docker build -t cmake-gcc:9 -f Sources/Dockerfile-gcc9 Sources
docker build -t cmake-gcc:10 -f Sources/Dockerfile-gcc10 Sources
# Run a build with g++-9
echo ""
echo "### Compiling with g++-9 and then running the result..."
docker run --rm --user $(id -u):$(id -g) -v $(pwd)/Sources:/Sources -v $(pwd)/Build:/Build -e CXX=g++-9 cmake-gcc:9
echo ""
# Run a build with g++-10
echo "### Compiling with g++-10 and then running the result..."
docker run --rm --user $(id -u):$(id -g) -v $(pwd)/Sources:/Sources -v $(pwd)/Build:/Build -e CXX=g++-10 cmake-gcc:10
echo ""
# Print success if we reach this point
echo "SUCCESS!"
I'm looking for the proper way to make the invocation of CMake succeed and rebuild all the project from scratch when a toolchain change happens.
The proper way is to use a fresh binary directory. Either remove the binary directory when changing and let it recreate or just use a separate different directory for each toolchain.
Use Build/gcc10 binary directory for gcc10 build and Build/gcc9 for gcc9 builds.
No need to cd Build and mkdir with nowadays cmake - use cmake -S. -BBuild. Also do not use make - prefer cmake --build Build to let you switch generator later.
"If you change the toolchain, you should start with a fresh build. There are too many things that assume the toolchain doesn’t change and while you may be able to find workarounds which appear to work, I recommend you always use a fresh build tree for a different toolchain. This same logic also applies if you update the existing toolchain in-place (e.g. you update to a newer version of GCC on Linux, a newer version of Xcode on macOS, etc.). CMake queries compiler capabilities and caches the results. If you change the toolchain in a way that CMake can’t catch, then you end up with stale cached capabilities being used for the new/updated toolchain. Please don’t do that." - Craig Scott
So essentially I don't think it's possible. You just need to blow away your build. The best thing you can do is alert users if CMake isn't doing it for you.
Perhaps reply on this also:
https://discourse.cmake.org/t/how-to-change-toolchain-without-breaking-developer-workflows/1166
Or start another discourse.
I'm trying to speed up build process using ramdisk for build directory.
I've created ramdisk:
sudo mount -t tmpfs -o size=1024m tmpfs /mnt/ramdisk
On ramdisk I've created build dir:
mkdir -p /mnt/ramdisk/rust/hello3/build/
Then I've symlinked ramdisk build dir to project in which I want to use this directory:
cd /home/wakatana/rust/hello3
ln -s /mnt/ramdisk/rust/hello3/build/ build
After this I did classic combo for building project:
cd /home/wakatana/rust/hello3/build
cmake ..
make
But above command does not worked because relative path (cmake ..) is translated to /mnt/ramdisk/rust/hello3 and not to /home/wakatana/rust/hello3/ (I suspect that this is whole problem)
So instead of classic combo I did a little bit modified combo (when build dir is not symlinked this works):
cd /home/wakatana/rust/hello3/build
cmake /home/wakatana/rust/hello3
make
But this ends up with errors during make phase:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/wakatana/rust/hello3/build
make[2]: *** No rule to make target '../src/lib.rs', needed by 'src/x86_64-unknown-linux-gnu/debug/libtest_lib.a'. Stop.
CMakeFiles/Makefile2:122: recipe for target 'src/CMakeFiles/test-lib_target.dir/all' failed
make[1]: *** [src/CMakeFiles/test-lib_target.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
Is it possible to somehow tell to cmake/make to deal symlinks correctly?
Just save yourself the trouble of creating symlinks and work on the ram disc:
cmake -S /home/wakatana/rust/hello3 -B /mnt/ramdisk/rust/hello3/build/
cmake --build /mnt/ramdisk/rust/hello3/build/
You could create the symlink, and then work from parent dir:
ln -s /mnt/ramdisk/rust/hello3/build/
cd /home/wakatana/rust/hello3
cmake -S . -B build
cmake --build build
# or expand the symlink before cmake has to:
cmake -S . -B "$(readlink -f "./build")"
cmake --build "$(readlink -f "./build")"
The other way is to rebind your RAM disk into your project tree instead of symlinking:
$ cd /home/wakatana/rust/hello3
$ mkdir -p build
$ mount --bind /mnt/ramdisk/rust/hello3/build build
I want to setup the ct-ng for my gui application and now I want to use wxwidgets.
For setting up the crosstool, I have used:
# Install prerequisites:
apt-get -y install gcc gperf bison flex gawk libtool automake libncurses5-dev texinfo
# Setup toolchain
# instructions from https://github.com/crosstool-ng/crosstool-ng
cd toolchain/crosstool-ng
./bootstrap
./configure --prefix=$HOME/.local
make && make install
echo -ne "\n\nif [ -d \"$HOME/.local/bin\" ]; then\n PATH=\"$HOME/.local/bin:$PATH\"\nfi" >> ~/.profile
source ~/.profile
mkdir ../tc/
cd ../tc/
ct-ng list-samples
ct-ng x86_64-w64-mingw32
ct-ng build # lasts 30 minutes...
##################### WxWidgets ######################
cd ../wxWidgets/
sh autogen.sh
./configure --prefix="$HOME/prefix" --enable-static --disable-shared --build=x86_64-w64-mingw32 --enable-unicode --without-libtiff --without-libjpeg --with-expat=builtin --with-libpng=builtin
make
The only way I have found is to clone wxwidgets from github and compile it as above in the script. Then, I included as path -I
WXWIDGET=../toolchain/wxWidgets/include/
$(CXX) -I$(FLEX) -I$(WXWIDGET) $(WXWIDGETSFLAGS) $(CPPFLAGS) $(header) $(src) $(obj3) -o $(OUTPUT)/$(bin)
Hundreds of errors appearing while compiling:
In file included from ../toolchain/wxWidgets/include/wx/platform.h:485:0,
from ../toolchain/wxWidgets/include/wx/defs.h:20,
from ../toolchain/wxWidgets/include/wx/string.h:24,
from ../toolchain/wxWidgets/include/wx/artprov.h:14,
from parser/include/gui.h:17,
from parser/include/customdialogs.h:17:
../toolchain/wxWidgets/include/wx/chkconf.h:282:9: error: #error "wxUSE_SECRETSTORE must be defined, please read comment near the top of this file."
# error "wxUSE_SECRETSTORE must be defined, please read comment near the top of this file."
What should I do?
You need to try "--host" and "--target" configure options.
Just try "../configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-shared --enable-unicode".
BTW, "--enable-unicode" should be turned on by default. So you can drop it.
Also, if you software required C++11, you should compile the library as:
CXXFLAGS="-std=c++11" ../configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-shared --enable-unicode
I'm currently compiling the latest version of Mono from Github on an original version Raspberry Pi, on latest Raspbian.
This is a very time consuming process, which when it's complete I would not like to have to repeat.
Can the compiled Mono installation be packaged into a .deb to, for example, allow me to re-install latest Raspbian, then dpkg -i my-mono-build.deb?
Sure, and it's very easy to do if you choose the proper tool so that you don't need a master on debian packaging. As for me, I chose fpm to do exactly this. (Note: install via gem, not apt-get.)
And here you have an example of a script of how to build a Mono .deb with this, which I copy+paste here for posterity (just in case I delete the github repo by mistake, or github stops being a thing in the future):
#!/bin/bash
set -e
die () {
echo >&2 "$#"
exit 1
}
[ "$#" -eq 1 ] || die "Please specify the version of Mono you want to build as the argument. (Check the versions in the tarball list here: http://download.mono-project.com/sources/mono/)"
which fpm > /dev/null || (echo "Please install fpm (from gem, not apt-get)" && exit 1)
if mono --version > /dev/null 2>&1; then
echo "Mono is installed locally; please uninstall first" && exit 1
fi
WORK_DIR=/tmp/7digital-mono-work
rm -rf $WORK_DIR
mkdir $WORK_DIR
cd $WORK_DIR
MONO_VERSION=$1
MONO_DIR="mono-$MONO_VERSION"
SEVEND_VERSION="701"
MONO7D_VERSION=$MONO_VERSION'.'$SEVEND_VERSION
MONO7D_NAME="mono-7d"
echo "Downloading $MONO_VERSION"
wget http://download.mono-project.com/sources/mono/mono-$MONO_VERSION.tar.bz2
tar -jxf mono-$MONO_VERSION.tar.bz2
TARGET_DIR="$WORK_DIR/destdir"
mkdir $TARGET_DIR
cd "$WORK_DIR/$MONO_DIR"
./configure --prefix=/usr
make
make install DESTDIR="$TARGET_DIR"
cd $WORK_DIR
fpm -s dir \
-t deb \
-n $MONO7D_NAME \
-v $MONO7D_VERSION \
-C $TARGET_DIR \
-d "libglib2.0-dev (>= 0)" \
usr/bin usr/lib usr/share usr/include usr/etc
echo "Done. Your package should be ready in $WORK_DIR"
I need to compile for the modules from mod_cluster using https 2.4.17 and I am having an issue compiling the modules. The process fails at the make step.
I have successfully build httpd 2.4.17 into and rpm and installed it without issue.
I am pulling the mod_cluster from source at: https://github.com/modcluster/mod_cluster
I am following procedure to build mod_cluster:
cd /mod_cluster//native/advertise # Advertise the first of four modules
./buildconf
./configure --with-apxs=/usr/bin/apxs
checking for Apache httpd installation... APXS is /usr/bin/apxs
apxs_support is true
Use of uninitialized value in concatenation (.) or string at /usr/bin/apxs line 222.
configure: creating ./config.status
config.status: creating Makefile
make
Makefile:10: //build/rules.mk: No such file or directory
make: *** No rule to make target `//build/rules.mk'. Stop.
I believe the issue with the top_builddir directive in the make file.
Note: That there is not /build/rules.mk being written to /
# Makefile.in for mod_proxy_cluster
# copy the source in the httpd Apache source tree
APACHE_BASE = /usr
top_builddir = /
# For .deps.
builddir = /srv/apache/mod_cluster-master/native/advertise
# For the apache includes
top_srcdir = /usr
include $(top_builddir)/build/rules.mk
SH_COMPILE = $(LIBTOOL) --mode=compile $(BASE_CC) -I../include -prefer-pic -c $< && touch $#
all: mod_advertise.so
mod_advertise.so: mod_advertise.la
$(top_builddir)/build/instdso.sh SH_LIBTOOL='$(LIBTOOL)' mod_advertise.la `pwd`
mod_advertise.la: mod_advertise.slo
$(SH_LINK) -rpath $(libexecdir) -module -avoid-version mod_advertise.lo
clean:
rm -f *.o *.lo *.slo *.so
rm -rf .libs
Thank you
mod_cluster master compiles just fine with httpd 2.4.17. You might take a look at my Dockerfile that shows how it is done. I've just triggered a new DockerHub build, it will be available on DockerHub eventually.
In order to be absolutely sure, I repeated the process on Fedora22 x86_64 a minute ago manually:
wget http://archive.apache.org/dist/httpd/httpd-2.4.17.tar.gz
wget http://archive.apache.org/dist/httpd/httpd-2.4.17-deps.tar.gz
tar xvf ..., cd ...
./configure --prefix=/opt/httpd-2.4.17-build --with-mpm=worker --enable-mods-shared=most --enable-maintainer-mode --with-expat=builtin --enable-ssl --enable-proxy --enable-proxy-http --enable-proxy-ajp --with-threads
git clone https://github.com/modcluster/mod_cluster.git
cd mod_cluster/native
modules="advertise mod_cluster_slotmem mod_manager mod_proxy_cluster";for module in $modules;do cd $module;./buildconf;./configure --with-apxs=/opt/httpd-2.4.17-build/bin/apxs;make clean;make;cd ..;done;
So, apparently, the problem lies with your httpd build. Could you share your src rpm?