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.
Related
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.
.. and why does it break my packaging build?
I am trying to build .deb packages for the latest git version of VLC.
Namely, I'm taking the "/debian" directory from my distros (ubuntu 15.10) source package for VLC (2.2.1) and copying/applying this to the latest git pull of VLC (which I am able to compile without problems).
When I run "debuild -b -uc -us" (works for VLC 2.2.1) for the git version, I get:
dpkg-buildpackage: host architecture amd64
fakeroot debian/rules clean
dh clean --parallel --with autoreconf
dh_autoreconf_clean
patching file ./autotools/ltmain.sh
Hunk #1 FAILED at 5800.
Hunk #2 FAILED at 6168.
2 out of 2 hunks FAILED -- saving rejects to file ./autotools /ltmain.sh.rej
dh_autoreconf_clean: patch -R -f --no-backup-if-mismatch -i /usr/share/dh-autoreconf/ltmain-as-needed.diff ./autotools/ltmain.sh
returned exit code 1
debian/rules:246: recipe for target 'clean' failed
make: *** [clean] Error 25
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
debuild: fatal error at line 1374:
dpkg-buildpackage -rfakeroot -D -us -uc -b failed
Building debian packages is nasty and the information is a bit scarce.
Any idea where such an error message might come from and why?
I had a similar problem, and was unable to find anything on Google except this question.
I deleted two files present in the Debian file I used, autoreconf.after and autoreconf.before.
I want to cross-compile python 2.7.3 for ARM.
I've followed this example:
https://gist.github.com/bmount/6929380
But during the last step with make install, I get an error:
running install
running install_lib
creating /_install
error: could not create '/_install': Permission denied
make: *** [sharedinstall] Erreur 1
This is how I have done my cross-compilation:
./configure
make python Parser/pgen
mv python hostpython
mv Parser/pgen Parser/hostpgen
make distclean
patch -p1 < ../Python-2.7.3-xcompile.patch
CC=arm-unknown-linux-gnueabihf-gcc CXX=arm-unknown-linux-gnueabihf-g++ AR=arm-unknown-linux-gnueabihf-ar RANLIB=arm-unknown-linux-gnueabihf-ranlib ./configure --host=arm-unknown-linux --build=x86_64-linux-gnu --prefix=/python
make HOSTPYTHON=./hostpython HOSTPGEN=./Parser/hostpgen BLDSHARED="arm-unknown-linux-gnueabihf-gcc -shared" CROSS_COMPILE=arm-unknown-linux-gnueabihf- CROSS_COMPILE_TARGET=yes HOSTARCH=arm-unknown-linux BUILDARCH=x86_64-linux-gnu
make install HOSTPYTHON=./hostpython BLDSHARED="arm-unknown-linux-gnueabihf-gcc -shared" CROSS_COMPILE=arm-unknown-linux-gnueabihf- CROSS_COMPILE_TARGET=yes prefix=../Python-2.7.3/_install
If I run this command with "sudo", I get an other error:
Creating directory ../Python-2.7.3/_install/lib/python2.7/config
Creating directory ../Python-2.7.3/_install/lib/pkgconfig
/bin/sh: 7: arm-unknown-linux-gnueabihf-ranlib: not found
When you use "sudo", not found the "arm-unknown-linux-", maybe you should add the path of the "arm-unknow-linux-" to the root's envirenment.
Building thrift 0.9.1 (support C, C++, java, C#, perl, python) on Ubuntu 13.04 I am getting this error.
./configure run without any options, make run without any options...
Making all in test
make[2]: Entering directory `/home/dvb/sw/thrift-0.9.1/test'
Making all in nodejs
make[3]: Entering directory `/home/dvb/sw/thrift-0.9.1/test/nodejs'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/dvb/sw/thrift-0.9.1/test/nodejs'
Making all in cpp
make[3]: Entering directory `/home/dvb/sw/thrift-0.9.1/test/cpp'
Makefile:832: warning: overriding commands for target `gen-cpp/ThriftTest.cpp'
Makefile:829: warning: ignoring old commands for target `gen-cpp/ThriftTest.cpp'
/bin/bash ../../libtool --tag=CXX --mode=link g++ -Wall -g -O2 -L/usr/lib -o libtestgencpp.la ThriftTest_constants.lo ThriftTest_types.lo ../../lib/cpp/libthrift.la -lssl -lcrypto -lrt -lpthread
libtool: link: ar cru .libs/libtestgencpp.a .libs/ThriftTest_constants.o .libs/ThriftTest_types.o
ar: .libs/ThriftTest_constants.o: No such file or directory
make[3]: *** [libtestgencpp.la] Error 1
make[3]: Leaving directory `/home/dvb/sw/thrift-0.9.1/test/cpp'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/dvb/sw/thrift-0.9.1/test'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dvb/sw/thrift-0.9.1'
make: *** [all] Error 2
dvb#dvb-u13:~/sw/thrift-0.9.1$
While this seems to be a defect in the 0.9.1 release tarball, it is not a problem in the top of tree pulled via git as of this afternoon.
The solution if one encounters this problem is to use a newer version of thrift by getting the source tree directly via git instead of downloading the tarball. The only difference in build is you will need to run bootstrap.sh before configure. This is well documented.
Note two additional helpful bits of data:
1. Configure to build --without-tests (Mike Johnson below - thanks)
2. This issue is fixed in 0.9.2 release (Luke below- thanks!)
I ran into this problem tonight and "fixed" it. The problem is that ar(1) can't find the .o files in the directory test/cpp/.libs. I'm sure that there's some missing magic in the Makefile.am in test/cpp, but I've neither the patience or automake-fu to fix that.
Instead, I just symlinked the .o files from test/cpp to test/cpp/.libs/. That fixes the build of the C++ tests.
cd thrift-0.9.1/test/cpp/.libs
for i in ../*.o; do echo $i; ln -s $i .; done
Thrift was since released with this compile problem. You can choose to skip compiling tests, instead:
./configure --without-tests
You can also try this:
./configure
(cd test/cpp; ln -s . .libs)
make install
This will simply link .libs back to test/cpp. "ar" will find the files there.
David V is right that 0.9.1 is broken but 0.9.2 works. The build instructions seem to be a broken link as well. So here are the commands that worked for me, from a fresh Ubuntu install:
# Install java if you don't have it
sudo apt-get install default-jre
# install build dependencies
sudo apt-get install libboost-dev libboost-test-dev libboost-program-options-dev libboost-system-dev libboost-filesystem-dev libevent-dev automake libtool flex bison pkg-config g++ libssl-dev
cd /tmp
curl http://archive.apache.org/dist/thrift/0.9.2/thrift-0.9.2.tar.gz | tar zx
cd thrift-0.9.2/
./configure
make
sudo make install
#test that it can run
thrift --help
(credit goes to these helpful instructions; I just replaced 0.9.1 with 0.9.2)
I happened to face this problem. You can try cp all test/cpp/*.o to .libs folder.
Or you can skip compiling tests.
cp test/cpp/*.o test/cpp/.libs/
I want to install gcc4.8.1 on ubuntu 10.04.
Here are my installing steps:
Install libgmp, libmpfr and libmpc.
After switch to gcc4.8.1 source code dir, run "./configure --prefix=/usr/bin/gcc4.8.1 --with-gmp=/opt/pkg/gmp5.1.2 --with-mpfr=/opt/pkg/mpfr3.1.2 --with-mpc=/opt/pkg/mpc1.0.1"
make
export LD_LIBRARY_PATH=/opt/pkg/gmp5.1.2/lib:/opt/pkg/mpfr3.1.2/lib:/opt/pkg/mpc1.0.1/lib
sudo make install.
In the last step I get this error:
/usr/local/sbin/gcc-4.8.1/host-i686-pc-linux-gnu/gcc/cc1: error while loading shared libraries: libmpc.so.3: cannot open shared object file: No such file or directory
make[5]: *** [install-exec-hook] Error 1
make[5]: Leaving directory `/usr/local/sbin/gcc-4.8.1/i686-pc-linux-gnu/libjava'
make[4]: *** [install-exec-am] Error 2
make[4]: Leaving directory `/usr/local/sbin/gcc-4.8.1/i686-pc-linux-gnu/libjava'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/usr/local/sbin/gcc-4.8.1/i686-pc-linux-gnu/libjava'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/usr/local/sbin/gcc-4.8.1/i686-pc-linux-gnu/libjava'
make[1]: *** [install-target-libjava] Error 2
make[1]: Leaving directory `/usr/local/sbin/gcc-4.8.1'
make: *** [install] Error 2
I have switched to the libmpc library path and tested libmpc.so.3 with ldd. It has been installed successfully. Why does it say it cannot open shared object libmpc.so.3? How can I fix it?
According to your suggest, I have installed gcc4.8.1 successfully. Here are my steps:
Remove gmp, mpfr and mpc from /opt/pkg.
Install gmp, mpfr and mpc with the default configure. These packages will be installed in /usr/local/lib.
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH.
Enter the gcc source dir, run "./configure".
make.
Add symbol links:
sudo ln -s /usr/local/lib/libgmp.so.10 /usr/lib/libgmp.so.10
sudo ln -s /usr/local/lib/libmpfr.so.4 /usr/lib/libmpfr.so.4
sudo ln -s /usr/local/lib/libmpc.so.3 /usr/lib/libmpc.so.3
sudo make install.
Than you KiaMorot. Thank you trojanfoe.
I don't believe any of the answers here address the issue. Your problem is the last two steps
export LD_LIBRARY_PATH=/opt/pkg/gmp5.1.2/lib:/opt/pkg/mpfr3.1.2/lib:/opt/pkg/mpc1.0.1/lib
sudo make install
exporting your LD_LIBRARY_PATH is correct, but then you reset all environment variables when you change to root user with sudo in the last step.
One way to get around this:
sudo -s # become root user
export LD_LIBRARY_PATH=/opt/pkg/gmp5.1.2/lib:/opt/pkg/mpfr3.1.2/lib:/opt/pkg/mpc1.0.1/lib
make install # don't use sudo here
If anybody stumbles upon this using their own manually-built version of libgmp, libmpfr and libmpc instead of the system-provided ones:
export LD_LIBRARY_PATH=/opt/your-prefix-directory
is necessary for make itself, i.e. even when gcc ./configure was run with
--with-gmp=/opt/your-prefix-directory --with-mpc=/opt/your-prefix-directory --with-mpfr=/opt/your-prefix-directory
you need to specify where the linker should go looking for libgmp and friends.
You have to check if the libmpc.so.3 is a successfully created symbolic link to libmpc.so.3.0.0. This error may arise because you have installed this library manually and the sym. link may be missing. You could try this:
sudo ln -s /opt/pkg/mpc1.0.1/lib/libmpc.so.3.0.0 /opt/pkg/mpc1.0.1/lib/libmpc.so.3
Syntax of ln is ln -s <real path to file> <symbolic link name>. For more check out the man page of ln.