I've been trying to compile a static QEMU executable for Windows on a Debian box, and ran into some problems. (I'm using this guide as a reference.)
When I compile without the static flag everything works but when I compile using the static flag I get the following error during the call to configure:
ERROR: zlib check failed
Make sure to have the zlib libs and headers installed.
This is the command line:
WORK=/media/Work/qemu
cd $WORK/build/w32
(export PKG_CONFIG_PATH=$WORK/install/w32/lib/pkgconfig ;
export PKG_CONFIG_PREFIX=$WORK/install/w32 ;
#export BASH_X=-x ;
bash $BASH_X ../../qemu.git/configure --target-list="i386-softmmu" \
--cross-prefix=i686-w64-mingw32- \
--extra-ldflags="-L$WORK/install/w32/lib" \
--extra-cflags="-I$WORK/install/w32/include" \
--static \
)
You can disable the zlib test using the command line input
./configure --disable-zlib-test
Zlib will be needed to build qemu, but it will not test for the library during configure. If the library is available in the proper location during build process, you can try the above command to proceed.
Related
I'm on Windows 10 and using the latest version of MSYS2 (with gcc installed: pacman -S gcc)
I'm trying to compile mingw-w64-headers and mingw-w64-crt from mingw-w64-v7.0.0
Inside of my MSYS2 installation directory C:\msys2 I have created the folder mingw-w64 which I reference in the prefix argument below.
To compile each of these I use the same steps (replace name of library where appropriate):
mkdir mingw-w64-crt && cd mingw-w64-crt
../mingw-w64-v7.0.0/mingw-w64-crt/configure --prefix=/mingw-w64
make
make install
This works for mingw-w64-headers however for mingw-w64-crt I encounter errors at the make step. Specifically: incompatible types when assigning to type 'mbstate_t' {aka 'struct anonymous'} from type 'int'. A more detailed error image can be found here.
I would appreciate some guidance as to how to proceed.
I suggest that you just open one of MSYS2's MinGW environments (by running mingw32.exe or mingw64.exe) and then install the complete MinGW-w64 toolchain by running this:
pacman -S $MINGW_PACKAGE_PREFIX-toolchain
The toolchain includes GCC, the MinGW-w64 libraries, and the MinGW-w64 headers. If those prebuilt MinGW-w64 things are good enough for you, then you're done.
If you want to compile your own MinGW-w64, then should be able to use the environment you just installed to do it. To double-check that you are using the right toolchain, run which gcc and make sure it returns /mingw64/bin/gcc or /mingw32/bin/gcc.
Performing the following has allowed me to successfully compile:
pacman -S $MINGW_PACKAGE_PREFIX-toolchain
mkdir mingw-w64-crt && cd mingw-w64-crt
../mingw-w64-v7.0.0/mingw-w64-crt/configure --prefix=/mingw-w64 --with-sysroot=/mingw64
make -j %NUMBER_OF_PROCESSORS%
make install
I downloaded Halide binaries for Linux. For compiling the tutorial programs(especially the autoscheduler program), I need to install g++ version 5.3. But, I am not able to install this particular version. How to solve the problem? Please find the instructions below copied from the link : https://github.com/halide/Halide/releases
Update 1:
I ran the command sudo apt install g++-5.3 . I got the error "Unable to locate the package g++5.3"
Update 2:
These are some of the errors I get.
Update 4:
I want to run this program :
https://halide-lang.org/tutorials/tutorial_lesson_21_auto_scheduler_generate.html.
The linux command is given at the very top of the above link. I am pasting it below:
g++ lesson_21_auto_scheduler_generate.cpp ../tools/GenGen.cpp -g -std=c++11 -fno-rtti -I ../include -L ../bin -lHalide -lpthread -ldl -o lesson_21_generate
Additionally, I moved the "libHalide.a" file from the lib folder to the bin folder and executed the commmand.
The problem is that you're on Windows, as your references to x86_64-pc-cygwin and /cygdrive/c in your screenshot indicate, but you're trying to use the Linux binaries. Cygwin is only source-compatible with Linux programs, not binary-compatible. Here's your choices:
Use the Windows or MinGW downloads instead of the Linux ones (you may have to switch to MinGW)
In Ubuntu in VirtualBox, just install g++ instead of g++-5.3, and then use the Linux download there
I am using Petalinux 2017.2 and the included tools to build a Linux image for a Zynq ZC702 board. I am trying to add a pre-compiled executable to my rootfs with a bitbake recipe.
SUMMARY = "Demo on ARM-Linux"
SECTION = "PETALINUX/apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = " \
file://Demo1.out \
"
FILES_${PN} = " \
/home/root/Demo/ \
/home/root/Demo/Demo1.out \
"
S = "${WORKDIR}"
do_install() {
install -d ${D}/home/root/Demo
install -m 0755 ${S}/Demo1.out ${D}/home/root/Demo
}
When I attempt to build the rootfs with my app included I get this error:
ERROR: demo-1.0-r0 do_package: objcopy failed with exit code 1 (cmd was 'arm-xilinx-linux-gnueabi-objcopy' --only-keep-debug '/home/common/peta_proj_2017.2_secure/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/demo/1.0-r0/package/home/root/Demo/Demo1.out' '/home/common/peta_proj_2017.2_secure/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/demo/1.0-r0/package/home/root/Demo/.debug/Demo1.out'):
arm-xilinx-linux-gnueabi-objcopy:/home/common/peta_proj_2017.2_secure/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/demo/1.0-r0/package/home/root/Demo/Demo1.out: File format not recognized
ERROR: demo-1.0-r0 do_package: Function failed: split_and_strip_files
I assume objcopy has an issue with my file having been compiled for arm-linux-gnueabihf, but I already know it works since I've tried copying it to the rootfs manually after Linux is booted and tested it. I would try to recompile it with the arm-xilinx-linux-gnueabi toolchain but it's missing some of the libraries I need. I don't know why objcopy is being called for this operation anyway. All I want is for it to move the file to the rootfs, but for some reason it's doing all this extra work on it. Is there a way I can make bitbake ignore the file's format?
looks like the problem is that objcopy is trying to strip symbols, and as you said, the toolchain used is not the same as the one it was used to build it.
You can try to setting:
INHIBIT_PACKAGE_STRIP="1"
somewhere (perhaps in your local.conf).
It should skip the step on which the build system tries to strip debug symbols from binaries hence will probably not invoke objcopy.
1 [https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-INHIBIT_PACKAGE_STRIP]1
I am trying to set up a cross compiling environment for the Raspberry Pi 3 on my Mac because compiling on the Pi just became to slow.
Following this guide I successfully created a cross compiler using crosstool-ng that is able to compile a simple "Hello World" program that runs on the Pi.
I try to follow the RaspberryPi2EGLFS-Guide on the Qt wiki.
It is written for Ubuntu but that should not make a difference when you have a compiler for your host system, does it?
I created the sysroot and fixed symbolic links as described in the guide, but the configure command for Qt fails.
./configure \
-release \
-opensource -confirm-license \
-make libs \
-opengl es2 \
-device linux-rpi3-g++ \
-sysroot $SYSROOT \
-opensource -confirm-license -make libs \
-prefix /usr/local/qt5pi -extprefix ~/dev/raspi/qt5pi \
-hostprefix ~/dev/raspi/qt5 \
-device-option CROSS_COMPILE=$TOOLCHAIN \
-v
There, $TOOLCHAIN points to the toolchain I compiled and $SYSROOT is the sysroot I set up according to the guide.
But the command fails with a bunch of errors because header files could not be found:
fatal error: sys/cdefs.h: No such file or directory
fatal error: zconf.h: No such file or directory
fatal error: sys/types.h: No such file or directory
Edit 12-14-2016
Apparently the compiler can't determine the cpu architecture:
/Volumes/xtools/armv8-rpi3-linux-gnueabihf/lib/gcc/armv8-rpi3-linux-gnueabihf/5.2.0/../../../../armv8-rpi3-linux-gnueabihf/bin/ld.gold: error: /Volumes/xtools/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/sysroot/usr/lib/crti.o: unknown CPU architecture
From my (limited) understanding, these headers should apear somewhere in $SYSROOT.
I have checked my sysroot, the missing headers a located in $SYSROOT/usr/include/arm-arm-linux-gnueabihf/.
I created a symlink from there to $SYSROOT/sys but that did not work either.
Am I missing something?
Other threads suggest installing g++-multilib on the host system, but there is no multlib-equivalent on macOS.
I want to have a static Universal binary lib of Boost. (Preferable the latest stable version, that is 1.43.0, or newer.)
I found many Google hits with similar problems and possible solutions. However, most of them seems outdated. Also none of them really worked.
Right now, I am trying
sudo ./bjam --toolset=darwin --link=static --threading=multi \
--architecture=combined --address-model=32_64 \
--macosx-version=10.4 --macosx-version-min=10.4 \
install
That compiles and install fine. However, the produced binaries seems broken.
az#ip245 47 (openlierox) %file /usr/local/lib/libboost_signals.a
/usr/local/lib/libboost_signals.a: current ar archive random library
az#ip245 49 (openlierox) %lipo -info /usr/local/lib/libboost_signals.a
input file /usr/local/lib/libboost_signals.a is not a fat file
Non-fat file: /usr/local/lib/libboost_signals.a is architecture: x86_64
Edit: It seems that the command was wrong and I must remove the "--" for most options. So the command I am trying now (-a just means to rebuild all):
sudo ./bjam -a toolset=darwin link=static threading=multi \
architecture=combined address-model=32_64 \
macosx-version=10.4 macosx-version-min=10.4 \
install
However, this gives many strange errors (what I already had earlier), all like this:
darwin.compile.c++.pch bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-combined/link-static/macosx-version-min-10.4/macosx-version-10.4/threading-multi/../src/tr1/pch.hpp.gch
In file included from ./boost/math/special_functions/acosh.hpp:18,
from ./boost/math/special_functions.hpp:15,
from libs/math/build/../src/tr1/pch.hpp:9:
./boost/config/no_tr1/cmath.hpp:21:19: error: cmath: No such file or directory
This could be another problem I have when building Universal binaries: g++ on MacOSX doesn't work with -arch ppc64
I found the problem. It seems that the MacOSX 10.4 SDK is missing a bunch of symlinks for GCC 4.2.
Use this as a test case:
g++ on MacOSX doesn't work with -arch ppc64
It will report multiple errors with GCC 4.2 (missing C++ includes, missing C includes, missing libs). In all cases, you can just fix that by setting a symlink. Search in your SDK for the file and just set the symlink in the same way it is in the MacOSX 10.5 SDK.
After that, it all just worked.
We use Boost compiled for 10.4 here at work. We don't use GCC 4.2 on it though, rather we use GCC 4.0 as Apple's GCC 4.2 is not supported for the MacOS 10.4 SDK. To accomplish this you need a bjam user config file, eg. user-config-darwin.jam. Here's the contents of ours. Modify to your heart's content:
# Boost.Build Configuration
# Compiler configuration
using darwin : 8.11 : /usr/bin/g++-4.0 :
<architecture>"combined"
<address-model>"32" # this can be changed to 32_64 for 32/64 universal builds
<macosx-version>"10.4"
<macosx-version-min>"10.4"
# <root>"/Developer"
<compileflags>""
<linkflags>"" ;
Then, you need to tell bjam to use the user config jam file when compiling:
bjam --user-config=user-config-darwin.jam ... (your other options go here) ...
Now you don't have to mess with symlinks in the system SDK directories.
To build 4-way universal boost static binaries on OSX 10.6 I do the following:
Download boost from the boost website.
Extract the archive and cd into the boost_1_xx_0 folder (where xx is the version of boost you are using).
Run:
./bootstrap.sh and then
./bjam macosx-version=10.6 macosx-version-min=10.4 architecture=combined threading=multi link=static address-model=32_64
This will compile everything except for Boost.MPI (which requires the --with-mpi option). The build products get put in ./stage