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

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.

Related

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

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!

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.

GNU gcc mysys make command no rule to make target libpng

I've searched around for the problem I encounter when I try to compile libpng, but I can't find a solution.
When I run:
C:\Users\Alex\Desktop\libpng-1.6.21\scripts>make makefile.gcc libpng.a
I receive the following messages:
make: Nothing to be done for `makefile.gcc'.
make: *** No rule to make target `libpng.a'. Stop.
I haven't modified the original makefile.gcc.
I think it's because you didn't call ./configure script.
Accoording to this wiki you need to run in msys shell:
wget http://sourceforge.net/projects/libpng/files/libpng15/older-releases/1.5.16/libpng-1.5.16.tar.xz/download
tar xvfJ libpng-1.5.16.tar.xz
cd libpng-1.5.16
mv INSTALL INSTALL.txt
./configure
make install

run qwt example in Qt 5 on linux ubuntu

I cant figure out what I need to do for running example program which use Qwt library.
I download the file qwt-6.1.2.tar.bz2 from here as usual it goes to Download Direcory and I extract the file to this directory. I have now qwt-6.1.2 directory in Downloads directory.
The Qt directory in my machine located in /opt/Qt5.4.1/
How I continue from here?
I try to run qmake:
natile#natile-Precision-T1650:/opt/Qt5.4.1/5.4/gcc_64/bin$ sudo ./qmake /home/natile/Downloads/qwt-6.1.2/qwt.pro
And after I ran make:
natile#natile-Precision-T1650:/opt/Qt5.4.1/5.4/gcc_64/bin$ sudo make
but I get an error:
cd src/ && ( test -e Makefile || /opt/Qt5.4.1/5.4/gcc_64/bin/qmake /home/natile/Downloads/qwt-6.1.2/src/src.pro -o Makefile ) && make -f Makefile
make[1]: Entering directory `/opt/Qt5.4.1/5.4/gcc_64/bin/src'
compiling /home/natile/qtcreator-projects/qwt/qwt-5.2/src/qwt_abstract_scale_draw.cpp
In file included from /home/natile/qtcreator-projects/qwt/qwt-5.2/src/qwt_abstract_scale_draw.cpp:19:0:
/home/natile/qtcreator-projects/qwt/qwt-5.2/src/qwt_scale_map.h:92:5: error: ‘QT_STATIC_CONST’ does not name a type
/home/natile/qtcreator-projects/qwt/qwt-5.2/src/qwt_scale_map.h:93:5: error: ‘QT_STATIC_CONST’ does not name a type
make[1]: *** [obj/qwt_abstract_scale_draw.o] Error 1
make[1]: Leaving directory `/opt/Qt5.4.1/5.4/gcc_64/bin/src'
make: *** [sub-src-make_first-ordered] Error 2
I understand that I have to run qmake.
I get nothing in the installation URL: http://qwt.sourceforge.net/qwtinstall.html
Please help.
The following approach works good for me:
cd /home/natile/Downloads/qwt-6.1.2/
mkdir build
/opt/Qt5.4.1/5.4/gcc_64/bin/qmake qwt.pro -o build/Makefile QWT_CONFIG="QwtExamples"
cd build
make
cd examples/bin
# Now you can launch any example, like:
./dials

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.