How to use ccache with Make? - c

I have a source directory which uses makefile to compile the code. This makefile/configure file is not written for ccache compatibility. So I thought to use ccache. I created alias in .bashrc as alias gcc='ccache gcc', but Makefile is still not considering this definition of gcc. So is there anything I can do without touching Makefile/configure file such that it takes ccache gcc instead of gcc.
Also CC='ccache gcc' ./configure is not an option, since it does not ask for CC.
If I write Makefile then I can provide ${gcc), but this is not an option, since I am not writing Makefile. Is there any way by which we don't need to change anything in source file, but still enable ccache compiling.

Aliases are local to the shell they are created in; unlike environment variables they are not passed to any programs that the shell invokes (including make). Make invokes /bin/sh, not /bin/bash, and /bin/sh doesn't read your ~/.bashrc etc. so no aliases defined there will be helpful to you.
I'm not exactly sure why you have placed some of the restrictions you mention on yourself: these things work fine and you haven't given a reason to avoid them that I understand. For example, providing a different CC with configure will work, if the version of autoconf is not really ancient. You can do this:
./configure CC='ccache gcc'
for example and that will set the default value of CC in your makefile to be ccache gcc. I don't know what you mean by "it does not ask for CC".
If you would prefer, you can also override the setting of CC on the make command line, like this:
make CC='ccache gcc'
which also works fine.

As described by the fine manual: Create a symlink named "gcc" in a directory that is listed in your PATH before the one containing the real gcc. This will cause ccache to be used transparently, with no need for any change to the makefile.

Add packaged ccache to PATH
PATH="/usr/lib/ccache:${PATH}" make
This is a versatile method, that:
works for all compilers at once: C, C++, etc.
depends less on the actual Makefile setup like CC could
does not break people's build if your are automating something and the target user does not have ccache installed
Mentioned at man ccache:
To use the second method on a Debian system, it's easiest to just prepend /usr/lib/ccache to your PATH. /usr/lib/ccache contains symlinks for all compilers currently installed as Debian
packages.
And you can confirm that with:
ls -l /usr/lib/ccache
which contains a ton of possible GCC names, including for installed cross compilers:
total 0
lrwxrwxrwx 1 root root 16 May 6 13:51 aarch64-linux-gnu-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 aarch64-linux-gnu-gcc-7 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jun 23 18:25 arm-linux-gnueabi-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jun 23 18:25 arm-linux-gnueabi-g++-7 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 arm-linux-gnueabi-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 arm-linux-gnueabi-gcc-7 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 22:11 arm-linux-gnueabihf-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 22:11 arm-linux-gnueabihf-gcc-7 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 arm-none-eabi-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 arm-none-eabi-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 arm-none-eabi-gcc-6.3.1 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 c++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 c89-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 c99-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 cc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 clang -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 clang++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 g++-5 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 g++-6 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 g++-7 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 gcc-5 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 gcc-6 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 gcc-7 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 x86_64-linux-gnu-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 x86_64-linux-gnu-g++-5 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 x86_64-linux-gnu-g++-6 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 x86_64-linux-gnu-g++-7 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 x86_64-linux-gnu-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 x86_64-linux-gnu-gcc-5 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 x86_64-linux-gnu-gcc-6 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 6 13:51 x86_64-linux-gnu-gcc-7 -> ../../bin/ccache
Tested on Ubuntu 16.04.

Related

Building PLX SDK driver in Linux yields "No such file or directory"

I am trying to build source code and running into grief.
[root#localhost Driver]# pwd
/usr/src/PlxSdk/Driver
[root#localhost Driver]# ls -la
total 36
drwxr-xr-x. 7 root root 183 Sep 15 18:10 .
drwxr-xr-x. 8 root root 123 Sep 15 18:10 ..
-rwxr-xr-x. 1 root root 658 Sep 15 18:10 buildalldrivers
-rwxr-xr-x. 1 root root 4524 Sep 15 18:10 builddriver
-rw-r--r--. 1 root root 590 Sep 15 18:10 Makefile
...
[root#localhost Driver]# ./buildalldrivers
------------------
Build: Plx8000_NT
- PLA: CentOS Linux release 8.2.2004 (Core)
- KER: 4.18.0-193.el8.x86_64
- INC: /lib/modules/4.18.0-193.el8.x86_64/build/include
- CPU: x86_64 (64-bit Little Endian)
- CMP: gcc
- TYP: 8000_NT Driver
- PKG: PCI/PCIe SDK v8.00
- CFG: Release
make[1]: *** /lib/modules/4.18.0-193.el8.x86_64/build: No such file or directory. Stop.
make: *** [/usr/src/PlxSdk/Makefiles/Targets.def:46: BuildDriver] Error 2
------------------
I saw this informative SO post, which talks of my problem, but none of the answers helped.
Use $ uname -r to check the kernel version
4.18.0-193.el8.x86_64
The complaint is No such file or directory, however there is a build directory and the kernel developer tools do exist.
[root#localhost Driver]# ls -la /lib/modules/4.18.0-193.el8.x86_64
total 16440
drwxr-xr-x. 6 root root 4096 Sep 15 20:20 .
drwxr-xr-x. 4 root root 64 Sep 14 14:27 ..
-rw-r--r--. 1 root root 295 May 8 07:07 bls.conf
lrwxrwxrwx. 1 root root 54 Sep 15 20:20 build -> ../../../usr/src/kernels/4.18.0-193.14.2.el8_2.x86_64/
-rw-r--r--. 1 root root 187648 May 8 07:07 config
drwxr-xr-x. 12 root root 128 Sep 14 14:27 kernel
-rw-r--r--. 1 root root 865312 Sep 14 14:31 modules.alias
-rw-r--r--. 1 root root 827199 Sep 14 14:31 modules.alias.bin
-rw-r--r--. 1 root root 488 May 8 07:07 modules.block
-rw-r--r--. 1 root root 7534 May 8 07:07 modules.builtin
-rw-r--r--. 1 root root 9748 Sep 14 14:31 modules.builtin.bin
-rw-r--r--. 1 root root 287699 Sep 14 14:31 modules.dep
-rw-r--r--. 1 root root 397124 Sep 14 14:31 modules.dep.bin
-rw-r--r--. 1 root root 365 Sep 14 14:31 modules.devname
-rw-r--r--. 1 root root 140 May 8 07:07 modules.drm
-rw-r--r--. 1 root root 59 May 8 07:07 modules.modesetting
-rw-r--r--. 1 root root 1602 May 8 07:07 modules.networking
-rw-r--r--. 1 root root 100539 May 8 07:07 modules.order
-rw-r--r--. 1 root root 553 Sep 14 14:31 modules.softdep
-rw-r--r--. 1 root root 414722 Sep 14 14:31 modules.symbols
-rw-r--r--. 1 root root 505717 Sep 14 14:31 modules.symbols.bin
lrwxrwxrwx. 1 root root 5 May 8 07:07 source -> build
-rw-r--r--. 1 root root 347581 May 8 07:07 symvers.gz
-rw-------. 1 root root 3909996 May 8 07:07 System.map
drwxr-xr-x. 2 root root 6 May 8 07:06 updates
drwxr-xr-x. 2 root root 40 Sep 14 14:27 vdso
-rwxr-xr-x. 1 root root 8913656 May 8 07:07 vmlinuz
-rw-r--r--. 1 root root 166 May 8 07:06 .vmlinuz.hmac
drwxr-xr-x. 3 root root 23 Sep 14 14:30 weak-updates
[root#localhost Driver]#
The build link is valid and blinking.
[root#localhost Driver]# ls -la /usr/src/kernels/4.18.0-193.14.2.el8_2.x86_64/
total 5348
drwxr-xr-x. 24 root root 4096 Sep 15 20:56 .
drwxr-xr-x. 3 root root 42 Sep 15 17:13 ..
drwxr-xr-x. 26 root root 4096 Sep 15 17:13 arch
drwxr-xr-x. 3 root root 78 Sep 15 17:13 block
drwxr-xr-x. 2 root root 37 Sep 15 17:13 certs
-rw-r--r--. 1 root root 187644 Jul 26 00:02 .config
drwxr-xr-x. 4 root root 76 Sep 15 17:13 crypto
drwxr-xr-x. 135 root root 4096 Sep 15 17:13 drivers
drwxr-xr-x. 2 root root 22 Sep 15 17:13 firmware
drwxr-xr-x. 73 root root 4096 Sep 15 17:13 fs
drwxr-xr-x. 30 root root 4096 Sep 15 17:14 include
drwxr-xr-x. 2 root root 37 Sep 15 17:14 init
drwxr-xr-x. 2 root root 22 Sep 15 17:14 ipc
-rw-r--r--. 1 root root 575 Jul 26 00:02 Kconfig
drwxr-xr-x. 17 root root 4096 Sep 15 17:14 kernel
drwxr-xr-x. 16 root root 4096 Sep 15 17:14 lib
-rw-r--r--. 1 root root 60925 Jul 26 00:02 Makefile
-rw-r--r--. 1 root root 1325 Jul 26 00:02 Makefile.rhelver
drwxr-xr-x. 3 root root 71 Sep 15 17:14 mm
-rw-r--r--. 1 root root 0 Sep 15 20:51 modules.order
-rw-r--r--. 1 root root 1241984 Jul 26 00:02 Module.symvers
drwxr-xr-x. 70 root root 4096 Sep 15 17:14 net
drwxr-xr-x. 26 root root 4096 Sep 15 17:14 samples
drwxr-xr-x. 13 root root 8192 Sep 15 17:14 scripts
drwxr-xr-x. 10 root root 151 Sep 15 17:14 security
drwxr-xr-x. 26 root root 4096 Sep 15 17:14 sound
-rw-r--r--. 1 root root 3910607 Jul 26 00:02 System.map
drwxr-xr-x. 2 root root 6 Sep 15 20:51 .tmp_versions
drwxr-xr-x. 29 root root 4096 Sep 15 17:14 tools
drwxr-xr-x. 2 root root 37 Sep 15 17:14 usr
drwxr-xr-x. 4 root root 44 Sep 15 17:14 virt
-rw-r--r--. 1 root root 41 Jul 26 00:02 vmlinux.id
[root#localhost Driver]#
sudo dnf install kernel-devel-$(uname -r)
Already installed
#Nighthawk663 in his answer stated Notice that the "source" link is also broken because it points to build. My Source link also points to build, but nothing that I did has it going anywhere else. I do not know if that is a valid comment or not.
[root#localhost Driver]# rpm -i /home/mnvme/Downloads/kernel-devel-4.18.0-193.el8.x86_64.rpm
package kernel-devel-4.18.0-193.14.2.el8_2.x86_64 (which is newer than kernel-devel-4.18.0-193.el8.x86_64) is already installed
[root#localhost Driver]#
The PLX SDK Linux Support Release Notes page stated some requirements, which I followed:
In order to build the files supplied, the shell environment variable PLX_SDK_DIR must be set. This should be set to the root location of where the PlxSdk folder is created.
# export PLX_SDK_DIR=$HOME/PlxSdk
#
# Or in my case
export PLX_SDK_DIR=/usr/src/PlxSdk
I did update my .bashrc file with that line and the comment.
I wanted to verify that gcc works and that there is no issue with the compiler, so I built the API and one of the samples. Here is the output from building one of the samples.
[root#localhost Samples]# cd ApiTest
[root#localhost ApiTest]# make
Build: ApiTest
- PLA: CentOS Linux release 8.2.2004 (Core)
- CPU: x86_64 (64-bit Little Endian)
- CMP: gcc
- TYP: Sample App
- PKG: PCI/PCIe SDK v8.00
- CFG: Release
CC /usr/src/PlxSdk/Samples/Shared/ConsFunc.c
CC /usr/src/PlxSdk/Samples/Shared/PlxInit.c
CC ApiTest.c
LNK ApiTest
Application "App/ApiTest" built successfully
[root#localhost ApiTest]# cd ..
[root#localhost Samples]#
As such, the problem is strictly building the driver and in particular there is something with the kernel that makes the build tools not happy.
Attempting to load the driver states that I did not build the driver, as expected. (I am also stating the load command for completeness sake.)
[root#localhost Bin]# ./Plx_load 8000d d
Install: Plx8000_DMA_dbg
Load module......... ERROR: Driver not built or invalid path
\-- /usr/src/PlxSdk/Driver/Source.Plx8000_DMA/Output/Plx8000_DMA_dbg.ko
[root#localhost Bin]#
NOTE:
The PLX Release Notes states the following, which apply to my problem.
Kernel 2.6
Kernel 2.6 introduced the Linux kernel build system. In order to build PLX drivers, or any other drivers for that matter, the Linux build system requires the following:
·Linux kernel development package, which matches the destination kernel version, must be installed
·In some cases, the current running kernel must be configured and built manually
If the PLX driver fails to build, please verify the requirements mentioned above are met.
I have the Linux kernel development package matching the destination kernel version as discussed previously, and I am not sure about the second point. I will investigate that.
Thoughts?
The specific answer to the problem was to create the symbolic link without the ../../.. like on the samples.
I executed as root the command from the /lib/modules/4.18... directory.
ln -s /usr/src/kernels/4.18.0-193.14.2.el8_2.x86_64/ build
Doing so then yielded a solid blue on black link to which I was able to do a CD into that.
I was then able to get to my next problem, but first problem resolved.
The funny thing is that I tried the above command before. Maybe I had to install something and then do that line. All I know is the culmination of everything above resolved the issue. Thanks to #JohnBollinger for the steer to the right direction.
[mnvme#localhost Driver]$ ./buildalldrivers
------------------
Build: Plx8000_NT
- PLA: CentOS Linux release 8.2.2004 (Core)
- KER: ver 4.18.0-193.14.2.el8_2.x86_64
- INC: /lib/modules/4.18.0-193.el8.x86_64/build/include
- CPU: x86_64 (64-bit Little Endian)
- CMP: gcc
- TYP: 8000_NT Driver
- PKG: PCI/PCIe SDK v8.00
- CFG: Release
arch/x86/Makefile:248: *** You are building kernel with non-retpoline compiler, please update your compiler.. Stop.
make: *** [/usr/src/PlxSdk/Makefiles/Targets.def:46: BuildDriver] Error 2
The solution to the non-retpoline error comes via a search and this post. I have to:
export the PLX_CHIP type of each project and make the project as root.
From a # prompt:
cd /usr/src/PlxSdk
export PLX_CHIP=8000_NT
make
export PLX_CHIP=8000_DMA
make
export PLX_CHIP=6000_NT
make
The 9000 code has a compiler bug.

Issues cross compiling iptables for arm

I am trying to cross compile iptables for ARM. I have tried versions 1.6.1 and 1.8.5 and both have similiar problems. iptables has three dependencies, libmnl, libnftnl and libnfnetlink. I have ensured all these are cross compiled and available in these locations -
/home/badri/arm_libs/nftnl2
/home/badri/arm_libs/mnl
/home/badri/arm_libs/nfnetlink
I had a similiar problem yesterday and it was related to configure. But now i feel configure is done right, but don't know what the problem is. This similiar problem can be seen here -
Issues cross compiling libnftnl for arm
My configure for iptables is as below -
./configure --build=x86_64-pc-linux-gnu --host=aarch64-linux-gnu --enable-static=no --prefix=/home/badri/arm_libs/iptables2 libmnl_LIBS=-L/home/badri/arm_libs/mnl/lib libmnl_CFLAGS=-I/home/badri/arm_libs/mnl/include/ libnftnl_LIBS=-L/home/badri/arm_libs/nftnl2/lib/ libnftnl_CFLAGS=-I/home/badri/arm_libs/nftnl2/include libnfnetlink_LIBS=-L/home/badri/arm_libs/nfnetlink/lib libnfnetlink_CFLAGS=-I/home/badri/arm_libs/nfnetlink/include
configure is successful and make results in these errors. Has anyone faced this problem ?
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:381: undefined reference to `nfnl_fill_hdr'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:387: undefined reference to `nfnl_addattr_l'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:389: undefined reference to `nfnl_query'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:384: undefined reference to `nfnl_fill_hdr'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:387: undefined reference to `nfnl_addattr_l'
/home/badri/Downloads/iptables-1.8.5/utils/nfnl_osf.c:389: undefined reference to `nfnl_query'
./configure --help looks like this.
badri#badri-All-Series:~/Downloads/iptables-1.6.1$ ./configure --help
`configure' configures iptables 1.6.1 to adapt to many kinds of systems.
Usage: ./configure [OPTION]... [VAR=VALUE]...
To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE. See below for descriptions of some of the useful variables.
Defaults for the options are specified in brackets.
Configuration:
-h, --help display this help and exit
--help=short display options specific to this package
--help=recursive display the short help of all the included packages
-V, --version display version information and exit
-q, --quiet, --silent do not print `checking ...' messages
--cache-file=FILE cache test results in FILE [disabled]
-C, --config-cache alias for `--cache-file=config.cache'
-n, --no-create do not create output files
--srcdir=DIR find the sources in DIR [configure dir or `..']
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[PREFIX]
By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc. You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.
For better control, use the options below.
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
--libexecdir=DIR program executables [EPREFIX/libexec]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
--libdir=DIR object code libraries [EPREFIX/lib]
--includedir=DIR C header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
--datadir=DIR read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR info documentation [DATAROOTDIR/info]
--localedir=DIR locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR man documentation [DATAROOTDIR/man]
--docdir=DIR documentation root [DATAROOTDIR/doc/iptables]
--htmldir=DIR html documentation [DOCDIR]
--dvidir=DIR dvi documentation [DOCDIR]
--pdfdir=DIR pdf documentation [DOCDIR]
--psdir=DIR ps documentation [DOCDIR]
Program names:
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
--program-transform-name=PROGRAM run sed PROGRAM on installed program names
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-silent-rules less verbose build output (undo: "make V=1")
--disable-silent-rules verbose build output (undo: "make V=0")
--enable-dependency-tracking
do not reject slow dependency extractors
--disable-dependency-tracking
speeds up one-time build
--enable-static[=PKGS] build static libraries [default=no]
--enable-shared[=PKGS] build shared libraries [default=yes]
--enable-fast-install[=PKGS]
optimize for fast installation [default=yes]
--disable-libtool-lock avoid locking (might break parallel builds)
--disable-ipv4 Do not build iptables
--disable-ipv6 Do not build ip6tables
--disable-largefile Do not build largefile support
--enable-devel Install Xtables development headers
--enable-libipq Build and install libipq
--enable-bpf-compiler Build bpf compiler
--enable-nfsynproxy Build SYNPROXY configuration tool
--disable-nftables Do not build nftables compat
--disable-connlabel Do not build libnetfilter_conntrack
Optional Packages:
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--with-pic[=PKGS] try to use only PIC/non-PIC objects [default=use
both]
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
--with-sysroot=DIR Search for dependent libraries within DIR
(or the compiler's sysroot if not specified).
--with-kernel=PATH Path to kernel source/build directory
--with-kbuild=PATH Path to kernel build directory
[[/lib/modules/CURRENT/build]]
--with-ksource=PATH Path to kernel source directory
[[/lib/modules/CURRENT/source]]
--with-xtlibdir=PATH Path where to install Xtables extensions
[[LIBEXECDIR/xtables]]
--with-pkgconfigdir=PATH
Path to the pkgconfig directory [[LIBDIR/pkgconfig]]
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
PKG_CONFIG path to pkg-config utility
PKG_CONFIG_PATH
directories to add to pkg-config's search path
PKG_CONFIG_LIBDIR
path overriding pkg-config's built-in search path
libnfnetlink_CFLAGS
C compiler flags for libnfnetlink, overriding pkg-config
libnfnetlink_LIBS
linker flags for libnfnetlink, overriding pkg-config
libmnl_CFLAGS
C compiler flags for libmnl, overriding pkg-config
libmnl_LIBS linker flags for libmnl, overriding pkg-config
libnftnl_CFLAGS
C compiler flags for libnftnl, overriding pkg-config
libnftnl_LIBS
linker flags for libnftnl, overriding pkg-config
YACC The `Yet Another Compiler Compiler' implementation to use.
Defaults to the first program found out of: `bison -y', `byacc',
`yacc'.
YFLAGS The list of arguments that will be passed by default to $YACC.
This script will default YFLAGS to the empty string to avoid a
default value of `-d' given by some make applications.
libnetfilter_conntrack_CFLAGS
C compiler flags for libnetfilter_conntrack, overriding
pkg-config
libnetfilter_conntrack_LIBS
linker flags for libnetfilter_conntrack, overriding pkg-config
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
Report bugs to the package provider.
badri#badri-All-Series:~/Downloads/iptables-1.6.1$
looks like it is also expecting LDFLAGS which shouldn't be the case. If i configured alongwith the options
LDFLAGS=-L/home/badri/arm_libs/nfnetlink/lib LIBS=-lnfnetlink
I can see that it seems to get past the linker errors for nfnl. And now it gets stuck at nftnl. Although ideally i would have expected the existing configure options to suffice.
This is difficult to say what exactly is causing your issue, but I would say that you may be missing -lnftnl linker option - my two cents.
This being said, I tried to cross-compile libmnl-1.0.4.tar.bz2, libnftnl-1.1.7.tar.bz2 and iptables-1.8.5.tar.bz2 using the following script, and all three compilations did succeed:
build.sh:
#/bin/bash
CROSS_COMPILE=/opt/arm/9/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-
mkdir sysroot
PREFIX=$(pwd)/sysroot
wget https://www.netfilter.org/projects/libmnl/files/libmnl-1.0.4.tar.bz2
wget https://www.netfilter.org/projects/libnftnl/files/libnftnl-1.1.7.tar.bz2
wget https://www.netfilter.org/projects/iptables/files/iptables-1.8.5.tar.bz2
tar jxf libmnl-1.0.4.tar.bz2
tar jxf libnftnl-1.1.7.tar.bz2
tar jxf iptables-1.8.5.tar.bz2
pushd libmnl-1.0.4
CC=${CROSS_COMPILE}gcc ./configure --build=x86_64-pc-linux-gnu --host=aarch64-linux-gnu --enable-static=no --prefix=${PREFIX}
make install
popd
pushd libnftnl-1.1.7
CC=${CROSS_COMPILE}gcc LIBMNL_CFLAGS="-I${PREFIX}/include" LIBMNL_LIBS="-L${PREFIX}/lib" ./configure --build=x86_64-pc-linux-gnu --host=aarch64-linux-gnu --enable-static=no --prefix=${PREFIX}
make install
popd
pushd iptables-1.8.5
CC=${CROSS_COMPILE}gcc libnftnl_CFLAGS="-I${PREFIX}/include" libnftnl_LIBS="-L${PREFIX}/lib -lnftnl" ./configure --build=x86_64-pc-linux-gnu --host=aarch64-linux-gnu --enable-static=no --prefix=${PREFIX}
make install
popd
After the script completed, iptables was available in sysroot/sbin:
ls -gG sysroot/sbin/
total 1424
lrwxrwxrwx 1 17 Aug 17 14:24 arptables -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-nft -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-nft-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-nft-save -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 arptables-save -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-nft -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-nft-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-nft-save -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ebtables-save -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables -> xtables-legacy-multi
lrwxrwxrwx 1 14 Aug 17 14:24 ip6tables-apply -> iptables-apply
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-legacy -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-legacy-restore -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-legacy-save -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-nft -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-nft-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-nft-save -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-restore -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-restore-translate -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 ip6tables-save -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 ip6tables-translate -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-legacy -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-legacy-restore -> xtables-legacy-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-legacy-save -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-nft -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-nft-restore -> xtables-nft-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-nft-save -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-restore -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-restore-translate -> xtables-nft-multi
lrwxrwxrwx 1 20 Aug 17 14:24 iptables-save -> xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 iptables-translate -> xtables-nft-multi
-rwxr-xr-x 1 373064 Aug 17 14:23 xtables-legacy-multi
lrwxrwxrwx 1 17 Aug 17 14:24 xtables-monitor -> xtables-nft-multi
-rwxr-xr-x 1 1079440 Aug 17 14:23 xtables-nft-multi
file sysroot/sbin/xtables-nft-multi
sysroot/sbin/xtables-nft-multi: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, not stripped
This may help you investigating your issue or cross-compiling iptables using the procedure above.

How to build a static version of the pcap library for Arm Linux

I saw libpcap here https://github.com/the-tcpdump-group/libpcap?files=1
I have compiler for arm linux.
How can I build libpcap to a file so I can statically link to this lib in my project?
I didn't find MakeFile for Arm.
On Ubuntu 16.04 86_64 or later, assuming bison and flex were installed, and gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf.tar.xz was downloaded and extracted into the /opt directory, a possible procedure for cross-compiling the latest version from scratch would be:
wget https://github.com/the-tcpdump-group/libpcap/archive/libpcap-1.9.1.tar.gz
tar zxf libpcap-1.9.1.tar.gz
cd libpcap-libpcap-1.9.1
CROSS_COMPILE=/opt/arm/9/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf- CC=${CROSS_COMPILE}gcc ./configure --host=arm-none-linux-gnueabihf --prefix=$(pwd)/libpcap-1.9.1-arm-none-linux-gnueabihf
CROSS_COMPILE=/opt/arm/9/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf- CC=${CROSS_COMPILE}gcc make install
The libraries and include files will be installed in libpcap-libpcap-1.9.1/libpcap-1.9.1-arm-none-linux-gnueabihf:
ls -gG -a libpcap-1.9.1-arm-none-linux-gnueabihf/include libpcap-1.9.1-arm-none-linux-gnueabihf/lib
libpcap-1.9.1-arm-none-linux-gnueabihf/include:
total 24
drwxr-xr-x 3 4096 Feb 6 13:07 .
drwxrwxr-x 6 4096 Feb 6 13:07 ..
drwxr-xr-x 2 4096 Feb 6 13:07 pcap
-rw-r--r-- 1 2294 Feb 6 13:07 pcap-bpf.h
-rw-r--r-- 1 2226 Feb 6 13:07 pcap.h
-rw-r--r-- 1 2024 Feb 6 13:07 pcap-namedb.h
libpcap-1.9.1-arm-none-linux-gnueabihf/lib:
total 2108
drwxr-xr-x 3 4096 Feb 6 13:07 .
drwxrwxr-x 6 4096 Feb 6 13:07 ..
-rw-r--r-- 1 1199090 Feb 6 13:07 libpcap.a
lrwxrwxrwx 1 12 Feb 6 13:07 libpcap.so -> libpcap.so.1
lrwxrwxrwx 1 16 Feb 6 13:07 libpcap.so.1 -> libpcap.so.1.9.1
-rwxr-xr-x 1 942752 Feb 6 13:07 libpcap.so.1.9.1
drwxr-xr-x 2 4096 Feb 6 13:07 pkgconfig
I hope this helps.
Just a remainder: Flex and Bison can be installed using:
sudo apt-get install flex bison

Using ALSA library on Linux

Ubuntu 18.04
I'm very new to sounds programming in Linux and I'm trying to work with ALSA library. I have alsa-library installed on my machine as follows:
/dev/snd$ sudo apt-file list libasound2
libasound2: /usr/lib/x86_64-linux-gnu/libasound.so.2
libasound2: /usr/lib/x86_64-linux-gnu/libasound.so.2.0.0
libasound2: /usr/share/doc/libasound2/NEWS.Debian.gz
libasound2: /usr/share/doc/libasound2/changelog.Debian.gz
libasound2: /usr/share/doc/libasound2/copyright
libasound2: /usr/share/doc/libasound2/examples/asoundrc.txt.gz
But the problem is that my header files are completely different from what is specified in the documentation Files section:
ll /usr/include/sound/
total 208
drwxr-xr-x 2 root root 4096 Nov 15 07:06 ./
drwxr-xr-x 41 root root 4096 Nov 11 10:26 ../
-rw-r--r-- 1 root root 21847 Oct 23 17:44 asequencer.h
-rw-r--r-- 1 root root 19132 Oct 23 17:44 asoc.h
-rw-r--r-- 1 root root 4377 Oct 23 17:44 asound_fm.h
-rw-r--r-- 1 root root 45851 Oct 23 17:44 asound.h
-rw-r--r-- 1 root root 6743 Oct 23 17:44 compress_offload.h
-rw-r--r-- 1 root root 16992 Oct 23 17:44 compress_params.h
-rw-r--r-- 1 root root 17240 Oct 23 17:44 emu10k1.h
-rw-r--r-- 1 root root 2697 Oct 23 17:44 firewire.h
-rw-r--r-- 1 root root 3140 Oct 23 17:44 hdsp.h
-rw-r--r-- 1 root root 5486 Oct 23 17:44 hdspm.h
-rw-r--r-- 1 root root 4304 Oct 23 17:44 sb16_csp.h
-rw-r--r-- 1 root root 7494 Oct 23 17:44 sfnt_info.h
-rw-r--r-- 1 root root 11574 Oct 23 17:44 snd_sst_tokens.h
-rw-r--r-- 1 root root 4041 Oct 23 17:44 tlv.h
-rw-r--r-- 1 root root 1939 Oct 23 17:44 usb_stream.h
For instance no conf.h header and as a consequence no struct snd_devname_t; definition. ALSA version I got from the alsa-info script is the latest one currently available.
!!ALSA Version
!!------------
Driver version: k4.15.0-36-generic
Library version: 1.1.3
Utilities version: 1.1.3
Should I install some other package to get the all includes available? I did some file search
$ find / -name alsa 2>/dev/null
/etc/default/alsa
/etc/apm/scripts.d/alsa
/run/alsa
/usr/share/alsa
/usr/share/sounds/alsa
/usr/src/linux-headers-4.15.0-39-generic/include/config/thinkpad/acpi/alsa
/usr/src/linux-headers-4.15.0-36-generic/include/config/thinkpad/acpi/alsa
/usr/src/linux-headers-4.15.0-34-generic/include/config/thinkpad/acpi/alsa
/var/lib/alsa
/sbin/alsa
and did not notice them.

Why does C library link order only matter on some systems?

My group developing a program which uses the JasPer library which depends on a JPEG library. My co-worker created a Makefile which listed the -ljpeg before -ljasper in the build rule. This worked fine on my co-worker's computer but would not build on mine:
$ make
cc -DDEBUG compress_image_test.c -o compress_image_test -Wall -ljpeg -ljasper -lm -lcheck
/usr/local/lib/libjasper.a(jpg_dec.o): In function `jpg_decode':
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_dec.c:158: undefined reference to `jpeg_std_error'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_dec.c:159: undefined reference to `jpeg_CreateDecompress'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_dec.c:162: undefined reference to `jpeg_stdio_src'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_dec.c:165: undefined reference to `jpeg_read_header'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_dec.c:168: undefined reference to `jpeg_start_decompress'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_dec.c:190: undefined reference to `jpeg_read_scanlines'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_dec.c:197: undefined reference to `jpeg_finish_decompress'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_dec.c:200: undefined reference to `jpeg_destroy_decompress'
/usr/local/lib/libjasper.a(jpg_enc.o): In function `jpg_encode':
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:284: undefined reference to `jpeg_std_error'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:285: undefined reference to `jpeg_CreateCompress'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:288: undefined reference to `jpeg_stdio_dest'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:294: undefined reference to `jpeg_set_defaults'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:310: undefined reference to `jpeg_set_quality'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:314: undefined reference to `jpeg_default_colorspace'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:317: undefined reference to `jpeg_start_compress'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:324: undefined reference to `jpeg_write_scanlines'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:329: undefined reference to `jpeg_finish_compress'
/cots/jasper-1.900.1/src/libjasper/jpg/jpg_enc.c:330: undefined reference to `jpeg_destroy_compress'
collect2: ld returned 1 exit status
make: *** [compress_image_test] Error 1
Both machines are running Ubuntu 12.04. The JasPer and JPEG libraries were built from source, not obtained through apt-get.
After reading another stack exchange post, lib dependencies and their order, I tried updating the makefile to swap the order of -ljpeg to after -ljasper. This worked.
So my question is, was the original order ok on another machine, which is basically equivalent to mine, but it did not work on my machine?
May 5th Update:
These are the relevant library files that I can find on my computer:
/usr/lib/i386-linux-gnu:
lrwxrwxrwx 1 root root 18 Jun 21 2012 libjasper.so.1 -> libjasper.so.1.0.0
-rw-r--r-- 1 root root 317148 Jan 11 2012 libjasper.so.1.0.0
lrwxrwxrwx 1 root root 16 Nov 22 07:42 libjpeg.so.8 -> libjpeg.so.8.0.2
-rw-r--r-- 1 root root 284436 Nov 22 07:42 libjpeg.so.8.0.2
/usr/local/lib:
-rw-r--r-- 1 root root 1361856 May 2 09:14 libjasper.a
-rwxr-xr-x 1 root root 757 May 2 09:14 libjasper.la
-rw-r--r-- 1 root root 1461672 May 2 09:15 libjpeg.a
-rwxr-xr-x 1 root root 918 May 2 09:15 libjpeg.la
lrwxrwxrwx 1 root root 16 May 2 09:15 libjpeg.so -> libjpeg.so.9.1.0
lrwxrwxrwx 1 root root 16 May 2 09:15 libjpeg.so.9 -> libjpeg.so.9.1.0
-rwxr-xr-x 1 root root 955739 May 2 09:15 libjpeg.so.9.1.0
And the same files as they exist on my co-workers computer:
/usr/lib/i386-linux-gnu:
lrwxrwxrwx 1 root root 18 Oct 29 2013 libjasper.so.1 -> libjasper.so.1.0.0
-rw-r--r-- 1 root root 317148 Jan 11 2012 libjasper.so.1.0.0
lrwxrwxrwx 1 root root 16 Nov 22 07:42 libjpeg.so.8 -> libjpeg.so.8.0.2
-rw-r--r-- 1 root root 284436 Nov 22 07:42 libjpeg.so.8.0.2
/usr/local/lib:
-rw-r--r-- 1 root root 1320124 Apr 24 16:01 libjasper.a
-rwxr-xr-x 1 root root 750 Apr 24 16:01 libjasper.la
-rw-r--r-- 1 root root 1462456 Apr 24 16:06 libjpeg.a
-rwxr-xr-x 1 root root 918 Apr 24 16:06 libjpeg.la
lrwxrwxrwx 1 root root 16 Apr 24 16:06 libjpeg.so -> libjpeg.so.9.1.0
lrwxrwxrwx 1 root root 16 Apr 24 16:06 libjpeg.so.9 -> libjpeg.so.9.1.0
-rwxr-xr-x 1 root root 955351 Apr 24 16:06 libjpeg.so.9.1.0
As far as I can see, all of the same files and links exist on the two systems.
You are probably linking against a static library.
With dynamic libraries, the whole library is included in the link, which will make all of its symbols available to objects mentioned later, while for a static library, only those archive members that satisfy currently undefined symbols are linked, and the rest of the library ignored.
There is two possibilities for dynamic libraries:
If you set LD_LIBRARY_PATH to include path that in it libjpeg.so could be found, then ld will search in these paths for libjpeg.so automatically when it find out that libjasper.so needs it.
That libjasper.so may be built with a -rpath ld option. In this case, ld also will search in that path for dependent libraries automatically.
You can find out whether there is a rpath in libjasper.so by readelf -d /path/to/libjasper.so.

Resources