undefined reference to `__printf_chk' when building from source with musl-g++ - c++

I'm attempting to compile a C++ library called VRPN with musl instead of glibc, and running into linker errors.
Dockerfile
# This build container compiles fully static binaries for alpine
FROM ekidd/rust-musl-builder:1.49.0 AS build
ENV CC=musl-gcc
ENV CXX=musl-g++
ENV CFLAGS=-static
ENV CXXFLAGS=-static
USER root
# Install build dependencies
RUN apt-get update && apt-get install -y cmake
# Install VRPN (VR peripheral device network)
WORKDIR /usr/local/src
RUN git clone --depth 1 --branch v07.34 https://github.com/vrpn/vrpn.git
RUN cd vrpn && git submodule update --init --recursive
RUN mkdir vrpn_Build
WORKDIR /usr/local/src/vrpn_Build
RUN cmake -DCMAKE_BUILD_TYPE=RELEASE \
-DVRPN_USE_GPM_MOUSE=OFF \
-DVRPN_BUILD_CLIENT_LIBRARY=OFF \
-DVRPN_BUILD_JAVA=OFF \
-DVRPN_BUILD_PYTHON_HANDCODED_3X=OFF \
-DVRPN_BUILD_SERVERS=OFF \
-DVRPN_USE_LIBUSB_1_0=OFF \
-DVRPN_USE_DEV_INPUT=OFF \
-DVRPN_USE_HID=OFF \
-DVRPN_USE_I2CDEV=OFF \
-DVRPN_USE_JOYLIN=OFF \
-DVRPN_USE_LIBUSB_1_0=OFF \
../vrpn
RUN make VERBOSE=1
Save the above to a file and run docker build . to get the following error (after lots of successful building):
Output
[ 72%] Linking CXX executable time_test
/usr/bin/cmake -E cmake_link_script CMakeFiles/time_test.dir/link.txt --verbose=1
/usr/bin/musl-g++ -static -fPIC -O3 -DNDEBUG -rdynamic CMakeFiles/time_test.dir/time_test.cpp.o -o time_test -L/usr/lib/x86_64-linux-musl libvrpnserver.a quat/libquat.a -lm atmellib/libvrpn_atmel.a gpsnmealib/libgpsnmea.a -Wl,-Bstatic -lgcc -lgcc_eh
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x12): undefined reference to `__libc_csu_fini'
(.text+0x19): undefined reference to `__libc_csu_init'
CMakeFiles/time_test.dir/time_test.cpp.o: In function `main':
time_test.cpp:(.text.startup+0x45): undefined reference to `__printf_chk'
time_test.cpp:(.text.startup+0xee): undefined reference to `__printf_chk'
time_test.cpp:(.text.startup+0x120): undefined reference to `__printf_chk'
collect2: error: ld returned 1 exit status
CMakeFiles/time_test.dir/build.make:100: recipe for target 'time_test' failed
make[2]: Leaving directory '/usr/local/src/vrpn_Build'
make[2]: *** [time_test] Error 1
CMakeFiles/Makefile2:973: recipe for target 'CMakeFiles/time_test.dir/all' failed
make[1]: Leaving directory '/usr/local/src/vrpn_Build'
make[1]: *** [CMakeFiles/time_test.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2
The command '/bin/sh -c make VERBOSE=1' returned a non-zero code: 2
It seems that for some reason, musl's glibc hasn't been linked correctly, but I've been unable to figure out why.
I've read that linking to pre-compiled objects is generally the cause of this type of issue, but in this case, I'm pretty confident that everything is being built from source.
I don't have much experience with compiler internals, and I'm having a hard time finding reading material about musl simple enough that I can understand. Any insight or pointers would be much appreciated.
Thanks!

I managed to figure this one out. I think I was using host libraries rather than a proper musl toolchain. I got it to work by building in the messense/rust-musl-cross docker image (created with musl-cross-make), which contains the gcc toolchain compiled for the x86_64-unknown-linux-musl target.
Here's my working docker build script for future reference.
# This build container compiles fully static binaries for alpine
FROM messense/rust-musl-cross:x86_64-musl AS build
USER root
# Install build dependencies
RUN apt-get update && apt-get install -y cmake
# Install VRPN (VR peripheral device network)
WORKDIR /usr/local/src
RUN git clone --depth 1 --branch v07.34 https://github.com/vrpn/vrpn.git
RUN cd vrpn && git submodule update --init --recursive
RUN mkdir vrpn_Build
WORKDIR /usr/local/src/vrpn_Build
RUN set -x
ENV TARGET=x86_64-unknown-linux-musl
ENV CC=$TARGET-gcc
ENV CXX=$TARGET-g++
RUN cmake -DCMAKE_BUILD_TYPE=Release \
-DVRPN_USE_GPM_MOUSE=OFF \
-DVRPN_BUILD_JAVA=OFF \
-DVRPN_BUILD_PYTHON_HANDCODED_3X=OFF \
-DVRPN_BUILD_SERVERS=OFF \
-DVRPN_BUILD_CLIENTS=OFF \
-DVRPN_USE_LIBUSB_1_0=OFF \
-DVRPN_USE_DEV_INPUT=OFF \
-DVRPN_USE_HID=OFF \
-DVRPN_USE_I2CDEV=OFF \
-DVRPN_USE_JOYLIN=OFF \
-DVRPN_USE_LIBUSB_1_0=OFF \
../vrpn
RUN make VERBOSE=1
Cheers!

Related

Docker/C++ problem - Compiling Error /usr/bin/ld: cannot open output file server: Is a directory

I'm trying to compile a C++ program using cmake in ubuntu containerized in Docker. Without Docker I can make it work just fine, but with it I seem to get some errors, whowever I can't seem to fix them :/
I've tried resolving to change the path to many different combinations in the hopes that I was just writing in the wrong path.
FROM ubuntu:16.04
# Set the working directory to /app
WORKDIR /app
# Copy the current directory contents into the container at /app
COPY . /app
# Install any needed packages specified in the requirements.txt
RUN apt-get update && apt-get -y install g++ make cmake-curses-gui libsqlite3-dev libmariadb-client-lgpl-dev subversion
# Make port 8078 available to the world outside this container
EXPOSE 8078
# Retrieve EOServ and build it
RUN svn checkout svn://eoserv.net/eoserv/trunk/ /app/eoserv
RUN cd /app/eoserv && mkdir build && cd build
RUN cmake -G "Unix Makefiles" /app/eoserv
RUN make
# Run ./eoserv when the container launches
RUN /app/eoserv/eoserv
# Here I've tried several options like
# RUN ./eoserv
# RUN cd /app/eoserv && ./eoserv
Expected results would be an eoserv binary in desired folder, it works when I don't run it in the docker image, but cmake it all by itself, without Docker.
Actual results are:
[ 91%] Building C object CMakeFiles/eoserv.dir/tu/sha256.c.o
[100%] Linking CXX executable eoserv
/usr/bin/ld: cannot open output file eoserv: Is a directory
collect2: error: ld returned 1 exit status
CMakeFiles/eoserv.dir/build.make:305: recipe for target 'eoserv' failed
make[2]: *** [eoserv] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/eoserv.dir/all' failed
make[1]: *** [CMakeFiles/eoserv.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
The command '/bin/sh -c make' returned a non-zero code: 2
The RUN instruction starts a new shell. So the commands you RUN previously will only be local to that shell, which includes things like cd, and the next RUN instruction will start a new shell without knowledge of the previous.
The instructions
RUN cd /app/eoserv && mkdir build && cd build
RUN cmake -G "Unix Makefiles" /app/eoserv
RUN make
needs to be combined into a single RUN instruction
RUN cd /app/eoserv && mkdir build && cd build && cmake -G "Unix Makefiles" /app/eoserv && make
You could of course write a script which runs the commands, and invoke that script with the RUN instruction.

Fix the build issue when using 'make' command when installing OSRM

I am setting up a OSRM server locally on a EC2 instance which is running Ubuntu 18.04.
I have followed the following steps to install OSRM:-
sudo apt update
sudo apt install -y git \
cmake \
build-essential \
jq \
liblua5.2-dev \
libboost-all-dev \
libprotobuf-dev \
libtbb-dev \
libstxxl-dev \
libbz2-dev
git clone https://github.com/Project-OSRM/osrm-backend.git
cd osrm-backend/
mkdir build
cd build/
cmake ..
make /* fails here */
On executing this in the given sequence, I get this error
[ 8%] Built target UTIL
[ 10%] Built target MICROTAR
[ 12%] Linking CXX executable osrm-components
CMakeFiles/osrm-components.dir/src/tools/components.cpp.o:components.cpp:function main: error: undefined reference to 'boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
collect2: error: ld returned 1 exit status
CMakeFiles/osrm-components.dir/build.make:132: recipe for target 'osrm-components' failed
make[2]: *** [osrm-components] Error 1
CMakeFiles/Makefile2:100: recipe for target 'CMakeFiles/osrm-components.dir/all' failed
make[1]: *** [CMakeFiles/osrm-components.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
Thanks in advance
Reinstalling everything in the same manner after deleting every related file and folder worked for me.

docker build error /usr/bin/ld: cannot find -lstdc++ fedora29

I'm trying to build a docker container using the following Dockerfile:
FROM fedora:29
RUN dnf -y update && dnf install -y file gcc gcc-c++ git make wget which libtool python3-pip redhat-rpm-config python3-devel zlib-devel libstdc++ openmpi-devel
RUN cd /tmp && \
wget http://www.mpich.org/static/downloads/3.3/mpich-3.3.tar.gz && \
gzip -dc mpich-3.3.tar.gz | tar xf - && \
cd mpich-3.3 && \
./configure --disable-fortran --prefix=/usr/mpich-3.3 && \
make && \
make install
ENV PATH /usr/mpich-3.3/bin:${PATH}
ENV LD_LIBRARY_PATH /usr/mpich-3.3/lib:${LD_LIBRARY_PATH}
RUN cd /usr && git clone https://github.com/Dowell-Lab/FStitch
RUN cd /usr/FStitch/src && make clean && make
RUN pip3 install FStitch-Bidir --user
ENV PATH /usr/FStitch/src:${PATH}
ENV PATH /root/.local/bin:${PATH}
RUN cd /usr && git clone https://github.com/Dowell-Lab/Tfit
RUN cd /usr/Tfit/src && make clean && make
ENV PATH /usr/Tfit/src:${PATH}
CMD /bin/bash
Where the projects I'm trying to clone are written in c++11 and the second of the two (Tfit) requires openmpi/mpich. The first program compiles successfully, but with the second, I'm getting the following error in the last step of the compiler:
/usr/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
make: *** [Makefile:20: NU_FIT] Error 1
I searched and found these two links:
cpp: usr/bin/ld: cannot find -l<nameOfTheLibrary>
usr/bin/ld: cannot find -l<nameOfTheLibrary>
But neither of these quite address the problem as I'm guessing I'm just missing a dependency/symlink to a library, but I'm unsure how to achieve this in the build. I can compile this successfully locally, but I have to module load mpi/openmpi-x86_64 to do so. My guess is that this is an openmpi issue when setting the LD_LIBRARY_PATH, but am unsure of how to resolve this in the Docker build.
The first few lines of the Makefile are as follows:
CXX = mpic++
CXXFLAGS = -static-libstdc++ -static-libgcc -Wno-unused-variable -Wno-non-virtual-dtor -std=c++11 -fopenmp -Wno-write-strings -Wno-literal-suffix -D_GLIBCXX_USE_CXX11_ABI=0 -g
EXEC = ${PWD}/Tfit
ARCH = getconf LONG_BIT
CPP_FLAGS_32 = -D32_BIT
CPP_FLAGS_64 = -D64_BIT
GCCVERSION = $(shell ${CXX} -dumpversion)
NU_FIT: main.o load.o split.o model.o across_segments.o template_matching.o \
read_in_parameters.o model_selection.o error_stdo_logging.o \
MPI_comm.o density_profiler.o bootstrap.o prelim_main.o model_main.o select_main.o FDR.o BIC.o ParamWrapper.o old_template_matching.o
#printf "linking : "
#${CXX} ${CXXFLAGS} ${PWD}/main.o ${PWD}/load.o ${PWD}/model_selection.o \
${PWD}/split.o ${PWD}/model.o ${PWD}/across_segments.o \
${PWD}/template_matching.o ${PWD}/read_in_parameters.o \
${PWD}/MPI_comm.o \
${PWD}/bootstrap.o ${PWD}/density_profiler.o \
${PWD}/prelim_main.o ${PWD}/model_main.o ${PWD}/BIC.o ${PWD}/FDR.o \
${PWD}/select_main.o ${PWD}/error_stdo_logging.o ${PWD}/ParamWrapper.o ${PWD}/old_template_matching.o -o ${EXEC} -lmpi
#cp ${PWD}/Tfit ${PWD}/EMGU
Any help is appreciated!
Try add libstdc++-static in your list of dnf install. (https://github.com/numenta/nupic/issues/1901)

Linking error: "relocation R_X86_64_32 ... can not be used when making a shared object; recompile with -fPIC"

I am attempting to compile Tox (specifically toxcore). When I attempt to compile it, I encounter the following error:
>make
make all-recursive
make[1]: Entering directory '/root/Tox/toxcore'
Making all in build
make[2]: Entering directory '/root/Tox/toxcore/build'
CCLD libtoxav.la
/usr/bin/ld: /usr/local/lib/libvpx.a(vpx_codec.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libvpx.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:1385: recipe for target 'libtoxav.la' failed
make[2]: *** [libtoxav.la] Error 1
make[2]: Leaving directory '/root/Tox/toxcore/build'
Makefile:506: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/root/Tox/toxcore'
Makefile:410: recipe for target 'all' failed
make: *** [all] Error 2
Following the error message, I have attempted to use fPIC by exporting C++ flags (export CXXFLAGS="$CXXFLAGS -fPIC"), by adding an argument to configure (./configure --enable-shared) and by editing the Makefile (changing CC = gcc to CC = gcc -fPIC), but these attempts have not worked and I still encounter the same error. What might be going wrong?
Here's the approach I have right now (on Ubuntu):
sudo apt-get install pkg-config
sudo apt-get install build-essential
sudo apt-get install libtool
sudo apt-get install autotools-dev
sudo apt-get install automake
sudo apt-get install checkinstall
sudo apt-get install check
sudo apt-get install git
sudo apt-get install yasm
cd ~
mkdir Tox
cd Tox
git clone https://github.com/jedisct1/libsodium.git
cd libsodium
git checkout tags/1.0.3
./autogen.sh
./configure && make check
sudo checkinstall --install --pkgname libsodium --pkgversion 1.0.0 --nodoc
sudo ldconfig
cd ..
git clone https://chromium.googlesource.com/webm/libvpx
cd libvpx
git checkout tags/v1.3.0
./configure
make
make install
cd ..
git clone https://github.com/irungentoo/toxcore.git
cd toxcore
autoreconf -i
./configure
make
sudo make install
cd ..
There must be a bug in the configuration script, it shouldn't come up with libvpx.a.
But worry not, since Ubuntu provides packages for both libvpx-dev and libsodium-dev, and using those seems to work just fine, so you should probably just do that unless there's some strong reason not to.
Also, unless you need classic toxcore, it seems c-toxcore is the successor, so you probably should use it instead.
Configuring with --enable-pic will add in the necessary -fPIC options, and works for me.

Building a Debian package tries to install to real /opt

This is again one these nice Debian packaging problems.
I have an app that installs to /opt (the install location is actually irrelevant, the same problem occurs with /usr):
OPT=1 ./configure && make && make install
I took a working Debian packaging from my other app, that used CMake, but the configuring, build and installation were similar. I modified the rules file a bit to build my new app:
build: build-stamp
build-stamp:
dh_testdir
# Add here commands to compile the package.
OPT=1 ./configure && $(MAKE) -j$(shell cat /proc/cpuinfo | grep processor | wc -l)
touch build-stamp
I left the installation part untouched:
install: build
dh_testdir
dh_testroot
dh_prep
dh_installdirs
# Add here commands to install the package into debian/<packagename>
DESTDIR=`pwd`/debian/`dh_listpackages` $(MAKE) install
Now, the problem is that when I try to build the package, it tries to install
to the real /opt and crashes:
mkdir: cannot create directory ‘/opt/snm’: Permission denied
make[1]: *** [install_target] Error 1
make: *** [install] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
debuild: fatal error at line 1361:
dpkg-buildpackage -rfakeroot -D -us -uc -i -b failed
I just can't figure out why my packaging doesn't work with my new app. Or alternatively, why it DID work with the other app :)
It seems that my install step was just ignoring the DESTDIR given by the Debian rules file.