In my project it is required to implement IPsec to packets programatically. Currently my system captures packets utilizing netfilter queue and readies the packet to be mangled. From this point on I am clueless on how to implement IPsec to these packets.
During my research I came across a linux kernel library names xfrm however this lacks documentation to get a firm grip on it (https://www.google.com/search?client=ubuntu&channel=fs&q=how+to+use+xfrm+c&ie=utf-8&oe=utf-8#channel=fs&q=linux+ipsec+xfrm+example). I would really appreciate if any of you experts would provide me with some examples to perform IPsec with xfrm or any alternative methods to implement IPsec.
Thank you very much
In kernel space look at this files
[Sasi#localhost linux]$ ls -l net/ipv4/xfrm4_*
-rw-r--r--. 1 root root 3957 Apr 19 20:09 net/ipv4/xfrm4_input.c
-rw-r--r--. 1 root root 3773 Apr 19 20:09 net/ipv4/xfrm4_mode_beet.c
-rw-r--r--. 1 root root 2135 Apr 19 20:09 net/ipv4/xfrm4_mode_transport.c
-rw-r--r--. 1 root root 3024 Apr 19 20:09 net/ipv4/xfrm4_mode_tunnel.c
-rw-r--r--. 1 root root 2494 Apr 19 20:09 net/ipv4/xfrm4_output.c
-rw-r--r--. 1 root root 7530 Apr 19 20:09 net/ipv4/xfrm4_policy.c
-rw-r--r--. 1 root root 6523 Apr 19 20:09 net/ipv4/xfrm4_protocol.c
-rw-r--r--. 1 root root 2494 Apr 19 20:09 net/ipv4/xfrm4_state.c
-rw-r--r--. 1 root root 2765 Apr 19 20:09 net/ipv4/xfrm4_tunnel.c
[Sasi#localhost linux]$ ls -l net/xfrm/*
-rw-r--r--. 1 root root 2246 Apr 19 20:09 net/xfrm/Kconfig
-rw-r--r--. 1 root root 342 Apr 19 20:09 net/xfrm/Makefile
-rw-r--r--. 1 root root 14094 Apr 19 20:09 net/xfrm/xfrm_algo.c
-rw-r--r--. 1 root root 766 Apr 19 20:09 net/xfrm/xfrm_hash.c
-rw-r--r--. 1 root root 3179 Apr 19 20:09 net/xfrm/xfrm_hash.h
-rw-r--r--. 1 root root 8683 Apr 19 20:09 net/xfrm/xfrm_input.c
-rw-r--r--. 1 root root 7816 Apr 19 20:09 net/xfrm/xfrm_ipcomp.c
-rw-r--r--. 1 root root 4874 Apr 19 20:09 net/xfrm/xfrm_output.c
-rw-r--r--. 1 root root 78405 Apr 19 20:09 net/xfrm/xfrm_policy.c
-rw-r--r--. 1 root root 3364 Apr 19 20:09 net/xfrm/xfrm_proc.c
-rw-r--r--. 1 root root 14582 Apr 19 20:09 net/xfrm/xfrm_replay.c
-rw-r--r--. 1 root root 56892 Apr 19 20:09 net/xfrm/xfrm_state.c
-rw-r--r--. 1 root root 1877 Apr 19 20:09 net/xfrm/xfrm_sysctl.c
-rw-r--r--. 1 root root 73048 Apr 19 20:09 net/xfrm/xfrm_user.c
Related
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.
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
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.
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.
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.