How to use cmake's 'make install' from a pbuilder env debian/rules script? - cmake

This is to compile and link a static library (so only a build time dependency) that the source is fetched from a repository (just like the source of the main program) on a ubuntu launchpad build bot.
currently i am doing:
#!/usr/bin/make -f
export PREFIX=/usr
export CFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
export CXXFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
%:
dh $#
override_dh_auto_configure:
cd src/munt;cmake -DCMAKE_CXX_FLAGS="-O3 -fomit-frame-pointer -flto" mt32emu;make;make install
#...compile of the program that depends on mt32emu...
But it fails with:
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/libmt32emu.a
CMake Error at cmake_install.cmake:36 (FILE):
file INSTALL cannot copy file
"/tmp/buildd/dosbox-0.74+20121225/src/munt/libmt32emu.a" to
"/usr/local/lib/libmt32emu.a".
make[2]: *** [install] Error 1
make[2]: Leaving directory `/tmp/buildd/dosbox-0.74+20121225/src/munt'
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory `/tmp/buildd/dosbox-0.74+20121225'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package
I: unmounting /var/cache/pbuilder/ccache filesystem
I: unmounting dev/pts filesystem
I: unmounting proc filesystem
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build//2751 and its subdirectories
The idea is to install a static library dependency that is is not packaged in the ubuntu repositories in the launchpad pbuilder env, so it can be used as if it was a system dependency already.
If i try to do 'sudo make install' (and add sudo to the build-deps in debian/control), it asks me for the 'pbuilder' password when testing locally, which i'm assuming will hang the machine on the ubuntu buildbots.
edit: it actually fails on the buildbots because 'no tty present and no askpass program specified'.

There are several things you can do to clean up your rules file, especially when you are using dh.
In the % target, all of the dh command take a parameter builddirectory, which specifies what directory you are building in. This tells the builder to cd to that directory and then call commands (make, cmake, etc.).
In addition, you should just let dh install the files for you. This is done automatically. You shouldn't have to call make install manually.
Here's a slightly easier-to-read rules file:
#!/usr/bin/make -f
export PREFIX=/usr
export CFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
export CXXFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
%:
dh $# --builddirectory=src/munt
override_dh_auto_configure:
cd src/munt && cmake -DCMAKE_CXX_FLAGS="-O3 -fomit-frame-pointer -flto" mt32emu
#...compile of the program that depends on mt32emu...

Is this just a permissions issue? (i.e. -- must use 'sudo' to install to '/usr/local'?)
Must you install it to '/usr/local'?
If it's just a static library, purely needed for the build of the "the program that depends on mt32emu" then you could put it anywhere, and just tell the dependent program where it is.
To install somewhere else, use -DCMAKE_INSTALL_PREFIX=/directory/where/you/have/write/privileges. Or use DESTDIR= with the make install.

I eventually 'solved' this by depending on launchpad repository dependencies, that is, building a whole package for the library and building that on launchpad and then importing the archive where that was placed to my other builds. Made it explicit i guess.

Related

having issues with installing perl modules :: Make had returned bad status, install seems impossible

good day - i am still having issues with installing perl modules
there seems to be issues with the make-file. i am trying to figure out what goes wrong here on my notebook.
cpan[1]> install Data::Dumper
Running install for module 'Data::Dumper'
Running make for S/SM/SMUELLER/Data-Dumper-2.161.tar.gz
Fetching with LWP:
http://mirrors.hostingromania.ro/cpan.org/authors/id/S/SM/SMUELLER/Data-Dumper-2.161.tar.gz
Fetching with LWP:
http://mirrors.hostingromania.ro/cpan.org/authors/id/S/SM/SMUELLER/CHECKSUMS
Checksum for /home/martin/.cpan/sources/authors/id/S/SM/SMUELLER/Data-Dumper-2.161.tar.gz ok
CPAN.pm: Building S/SM/SMUELLER/Data-Dumper-2.161.tar.gz
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Data::Dumper
Writing MYMETA.yml and MYMETA.json
cp Dumper.pm blib/lib/Data/Dumper.pm
Running Mkbootstrap for Dumper ()
chmod 644 "Dumper.bs"
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- Dumper.bs blib/arch/auto/Data/Dumper/Dumper.bs 644
"/usr/bin/perl" "/usr/lib/perl5/5.18.2/ExtUtils/xsubpp" -typemap '/usr/lib/perl5/5.18.2/ExtUtils/typemap' Dumper.xs > Dumper.xsc
mv Dumper.xsc Dumper.c
cc -c -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -DVERSION=\"2.161\" -DXS_VERSION=\"2.161\" -fPIC "-I/usr/lib/perl5/5.18.2/x86_64-linux-thread-multi/CORE" -DUSE_PPPORT_H Dumper.c
/bin/sh: cc: Kommando nicht gefunden.
Makefile:332: recipe for target 'Dumper.o' failed
make: *** [Dumper.o] Error 127
SMUELLER/Data-Dumper-2.161.tar.gz
/usr/bin/make -- NOT OK
Running make test
Can't test without successful make
Running make install
Make had returned bad status, install seems impossible
Failed during this command:
SMUELLER/Data-Dumper-2.161.tar.gz : make NO
cpan[2]>
well - i need to make sure that the make is set propperly ..good day - i am still having issues with installing perl modules
there seems to be issues with the make-file. i am trying to figure out what goes wrong here on my notebook.
A C compiler is required to build that module, but the C compiler which perl was built with, 'cc' isn''t available. You will need to install that first.
But Data::Dumper is part of the standard perl distribution, so you shouldn't need to install it anyway. If you're using a Linux distribution where the perl installation has been split into multiple packages, then you may just need to do something like
yum install perl-Data-Dumper

Error when linking GSL with -static

I have written a programm in c++. Linking and runiing is working, as long as I don't use the "-static" option for g++. But I have to run it from an Antergos USB-Live Stick with default settings and there is no GSL included. In the manual of GSL they recommend
$ g++ -c main.cpp
$ g++ -static main.o -lgsl -lgslcblas -lm -lnlopt
But for this code I receive an error message:
/usr/bin/ld: cannot find -lgsl
/usr/bin/ld: cannot find -lgslcblas
collect2: Fehler: ld gab 1 als End-Status zurück
I tried it as this question, but it didn't work for me. When I run
$ g++ -O2 -o test main.cpp -lgsl -lgslcblas -lnlopt -lm
$ lld test
it prints
linux-vdso.so.1 (0x00007fffa5b95000)
libgsl.so.19 => /usr/lib/libgsl.so.19 (0x00007f8748c9a000)
libgslcblas.so.0 => /usr/lib/libgslcblas.so.0 (0x00007f8748a5d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f87486d5000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f87483d1000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f87481ba000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f8747e1c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f87490fe000)
So I tried to create a symlink, but I do have also "libgsl.so"
$ ls /usr/lib/libgsl
libgslcblas.so libgslcblas.so.0.0.0 libgsl.so.19
libgslcblas.so.0 libgsl.so libgsl.so.19.3.0
Am I doing something stupid? Thank your for your help.
When you pass -lgsl, by default you request the linker to
find and link either the shared library libgsl.so or the static
library libgsl.a and to prefer the shared library, if both are found
in the same search directory. The linker will search, first, in any
directories you have specified with the -L/path/to/search options,
in the order you specified, and then in its default search directories
(/usr/lib, etc.). Likewise for -lgslcblas.
But when you pass the linkage option -static to gcc/g++, it prevents
linking with any shared libraries. Shared libraries, libgsl.so, libgslcblas.so
will be ignored. Static libraries libgsl.a, libgslblas.a, must be
found, in some or other of the search directories, for the linkage to
succeed.
The linker is saying:
/usr/bin/ld: cannot find -lgsl
/usr/bin/ld: cannot find -lgslcblas
because it can't find those static libraries - presumably because you
haven't installed them.
You do not say what linux distro you are working on, but if the package
that provides libgsl and libgslcblas is called, say, libgsl[suffix]
then there will be a corresponding package called libgsl-dev, libgsl-devel,
or similar. This will be the development version of the package,
for the use of people who want to develop software that links with libgsl
or libgslcblas. The development package will require the libgsl package as a dependency
- so it will install the same stuff - and will in addition contain the
library's header files and the static version of the library.
So you need to install the libgsl development package for your distro.
For Ubuntu, for example, that is libgsl-dev:
Later
I gather that your distro, Arch Linux, does not do separate dev packages. You
need to build the static libraries from source. To do that you will need
at least to have installed:
GNU Make
GNU autotools (autoconf, automake, libtool)
GCC (C compiler)
texinfo
Then to make a default build:
Get the gsl source package from https://savannah.gnu.org/git/?group=gsl
either by cloning the git repo or downloading a current tar.gz tarball
and extracting it.
cd into the package directory.
run ./autogen.sh. This will succeed provided the GNU autotools prerequisites
are fulfilled.
run ./configure --enable-maintainer-mode (as ./autogen.sh will have prompted you).
This will succeed provided that the package dependencies are satisfied
and environment sanity checks pass.
run make
If make completes without errors - which will take a matter of minutes -
then, as root, run make install.
If all is well, this will install your missing static libraries:
/usr/local/lib/libgsl.a
/usr/local/lib/libgslcblas.a
You should not need to modify your linkage command for the linker to find
them: /usr/local/lib is a default linker search path.

gfortran cannot read its own creation

I am trying to compile a code with gfortran. One of the first things that happens in the compilation is the creation of constants.mod. Soon after that gfortran tells me:
Fatal Error: Cannot read module file ‘constants.mod’ opened at (1), because it was created by a different version of GNU Fortran
Now here's the thing: This module file is created by the same gfortran that it's trying to read it. gfortran creates the thing itself and then 1 second later thinks the file was created by some other version! Any idea what's going on here?
You'll probably want to see the compile command:
mpif90 -c -O3 -ISDF/FORTRAN/include -I/usr/include -Iobj -Jobj -o obj/shared_data.o src/core/shared_data.F90
shared_data.F90 contains the module constants at the top of the file.
EDIT: Here's the compile command followed by the full error message:
$> mpif90 -c -O3 -ISDF/FORTRAN/include -I/usr/include -Iobj -Jobj -o obj/shared_data.o src/core/shared_data.F90
src/core/shared_data.F90:67:6:
USE constants
1
Fatal Error: Cannot read module file ‘constants.mod’ opened at (1), because it was created by a different version of GNU Fortran
compilation terminated.
UPDATE: I hope you'll agree this is weird. The file that is failing is in src/core. If I cd to src/core and issue this command:
mpif90 -c -O3 -I../../SDF/FORTRAN/include -I../../obj -J../../obj -o ../../obj/shared_data.o shared_data.F90
it compiles just fine! But then I clean everything out of the obj directory and I cd two levels up and issue:
mpif90 -c -O3 -ISDF/FORTRAN/include -Iobj -Jobj -o shared_data.o src/core/shared_data.F90
and it fails with the error I showed above! What is the difference??? Thanks.

Problems adding DKMS support to kernel module

I'm trying to add DKMS support in a kernel module i'm working on.
I have placed the kernel module source with a static lib to be linked against in the following directory:
/usr/src/dpx/1.0
With the following files:
dkms.conf
Makefile
dpxmtt.c
lib.a
dkms.conf file is like this:
MAKE="make"
CLEAN="make clean"
BUILT_MODULE_NAME=dpx
BUILT_MODULE_LOCATION=src/
DEST_MODULE_LOCATION=/kernel/drivers/input/touchscreen
PACKAGE_NAME=dpxm
PACKAGE_VERSION=1.0
REMAKE_INITRD=yes
And the makefile is like this:
EXTRA_CFLAGS+=-DLINUX_DRIVER -mhard-float
obj-m += dpx.o
dpx-objs:= dpxmtt.o ../source/lib.a
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
The ../source/lib.a is an hack since when the makefile is invoked by the dkms building system it was saying that it couldn't be found in directory (the build directory), but since it was being copied to the source directory, i'm referencing it relatively.
When I call
sudo dkms build -m dpx -v 1.0
The result is almost perfect:
santos#NS-PC:~$ sudo dkms build -m dpx -v 1.0
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area....
make KERNELRELEASE=3.0.0-14-generic....
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
Consult the make.log in the build directory
/var/lib/dkms/dpx/1.0/build/ for more information.
nsantos#NS-PC:~$
And the content of the log file is:
DKMS make.log for dpx-1.0 for kernel 3.0.0-14-generic (i686)
Thu Jan 19 11:07:54 WET 2012
make -C /lib/modules/3.0.0-14-generic/build M=/var/lib/dkms/dpx/1.0/build modules
make[1]: Entering directory `/usr/src/linux-headers-3.0.0-14-generic'
CC [M] /var/lib/dkms/dpx/1.0/build/dpxmtt.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.o
Building modules, stage 2.
MODPOST 1 modules
CC /var/lib/dkms/dpx/1.0/build/dpx.mod.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.0.0-14-generic'
The module was built correctly but it ends with the error:
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
And I don't know what it means. Does anybody know?
Using:
$(shell uname -r)
in the Makefile it might be also wrong! The "shell uname -r" refers to the currently running kernel, but the main reason to use the dkms it's because it offers an automated method to recompile the kernel modules that reside outside of the kernel tree for every newly installed kernel. What i mean is that the Makefile might refers to a different kernel which the dkms is building the module for.
Use:
${kernelver} instead.
I had a similar problem. I think your BUILT_MODULE_LOCATION is set incorrectly to the src directory. It should be set in your example to the current directory, or you can just omit this variable and dkms would default to the current directory.

Compiling GDC on Windows -- where to get GMP and MPFR dependencies?

I'm trying to compile GDC (v2) on Windows 7, using MinGW's MSYS.
When I get to this step:
$ ../configure --enable-languages=d --disable-shared --disable-bootstrap
I get:
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gnatbind... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... no
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.
This made me look back at the instructions, which noted that it needs these libraries:
libgmp3-dev
libmpfr-dev
libmpc-dev
So now the question is, where do I find these headers and/or libraries? I've searched all over for libgmp3-dev, but I can't find anything for Windows. (I'm still in the learning process for *nix, so I'm not too familiar with anything.)
Thanks!
Update:
So I tried to make MPFR (I don't even know if it was the right version), and I got this error:
$ make install
Making install in tests
[...]
test -z "/usr/local/lib" || /bin/mkdir -p "/usr/local/lib"
/bin/sh ./libtool --mode=install /bin/install -c libmpfr.la '/usr/local/lib'
libtool: install: /bin/install -c .libs/libmpfr.lai /usr/local/lib/libmpfr.la
libtool: install: /bin/install -c .libs/libmpfr.a /usr/local/lib/libmpfr.a
libtool: install: chmod 644 /usr/local/lib/libmpfr.a
libtool: install: ranlib /usr/local/lib/libmpfr.a
/bin/sh: /home/Home: No such file or directory
make[2]: *** [install-libLTLIBRARIES] Error 127
make[2]: Leaving directory `/home/Home User/mpfr-2.4.2'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/Home User/mpfr-2.4.2'
make: *** [install-recursive] Error 1
Any ideas?
From https://bitbucket.org/goshawk/gdc/wiki/MinGWCompile :
ftp://ftp.gmplib.org/pub/gmp-5.0.1/gmp-5.0.1.tar.bz2
http://www.mpfr.org/mpfr-current/mpfr-3.0.0.tar.bz2
http://gmplib.org/
http://www.mpfr.org/
Just download the source tarballs. As for building these, I don't remember the details (the instructions should be clear on this) but I know you can put these GMP and MPFR in the source tree with GCC and the GCC build process will automatically take care of building these. This may be easier than building/installing/setting environment variables for them as a discrete step.
I always use this for building gdc on Windows: http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php
The error message you posted has the links to find the libraries. You might need to download their source code and compile them, but they are both easy to build.