I am developing an application that will make use of some of the sctp APIs like sctp_bindx, sctp_connectx etc.
My Linux kernel version is 3.13.0-49-generic .
If I try to compile my code , I get the below error
fatal error: netinet/sctp.h: no such file or directory.
If I install lksctp-tools package then my code got compiled.
Can I use the APIs without installing any libsctp library ? Since I read that SCTP is supported by the kenal version > 2.1
All functions require some library. It just happens that glibc is automatically used whenever you use gcc.
SCTP-specific functions are not included in glibc itself, so you need to install and use the sctp library. The fact that kernel supports SCTP is irrelevant here.
Related
I am trying to cross-compile my Rust project on Mac OS to Linux using cargo build --target=x86_64-unknown-linux-musl.
I installed the binary for Linux + musl cross-compilation on mac using brew install FiloSottile/musl-cross/musl-cross as I would ideally want a standalone binary.
I also installed the target using rustup target add x86_64-unknown-linux-gnu
And I have the following in my .cargo/config:
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"
However, I ran into issues with 2 libraries - sqlite3 and pcap:
= note: /usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lsqlite3
/usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lpcap
collect2: error: ld returned 1 exit status
I was able to solve the sqlite3 linker issue by adding features = ["bundled"] to my Cargo.toml file (similar to what is described here - https://users.rust-lang.org/t/linker-cannot-find-lsqlite3/23230/18) as that likely built it from source (which was great) but when I tried doing the same with pcap, it gave the following error:
the package `myProject` depends on `pcap`, with features: `bundled` but `pcap` does not have these features.
After reading somewhere I also tried (with low hopes) of providing the path to the installed libpcap on mac using RUSTPATH='-L/...' cargo build ... but that resulted, of course in undefined symbol errors.
Any ideas how can I get past this issue and cross compile my Rust project into a statically linked binary on macos to run on linux?
Cross compilation does not magically take care of libraries. You cannot just say "I want musl" and have something take care of all your dependencies.
The error message you are seeing is telling you exactly this: it cannot find libsqlite3 and libpcap.
The reason the error for sqlite disappears is because your sqlite library has a bundled feature, which replaces the linking with a built-in sqlite client. This, however, also requests the pcap bundled feature, which does not exist.
You have two options:
If you do not mind the performance loss in the bundled sqlite client, change your feature definition to target the feature of the dependency requiring sqlite
If you want the raw library itself, you will have to compile it for musl
No matter what happens, you will need to cross-compile libpcap for musl with the default sysroot provided by your musl compiler. As this varies per library, you will need to consult the libpcap documentation. once you have done so, you should be able to use the -lpcap flag, and the error will resolve itself.
I want to build a application which supports eBPF on CentOS 7 (the kernel version is 3.10.0):
if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, prog_fd, sizeof(prog_f)) {
......
}
So I download a 4.0.5 version, make the following configurations on:
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
Then follow this link to build and install a 4.0.5 kernel.
After executing make modules_install install, I find there is still no SO_ATTACH_BPF in <asm-generic/socket.h>, so the above code can't be compiled successfully.
How to build Linux kernel to support SO_ATTACH_BPF socket option?
In my setup, which is based on Fedora 21, I use very similar steps to those you linked to compile and install the latest kernel. As an additional step, I will do the following from the kernel build tree to install the kernel header files into /usr/local/include:
sudo make INSTALL_HDR_PATH=/usr/local headers_install
This will cause both the stock kernel header files to remain installed in /usr/include/{linux,asm,asm-generic,...}, and the new kernel header files to be installed in /usr/local/include/{linux,asm,asm-generic,...}. During your test program compile, depending on which build system you use, you may need to prefix gcc/clang with -I/usr/local/include.
Your newly installed kernel supports SO_ATTACH_BPF, but your current libc package doesn't now about that (as you mention, distro's native 3.10.0 kernel lacks of given option support).
You need to update libc package as well for use new kernel's features in user space programs.
I'm trying to install gcc4.9 on a SUSE system without an internet connection. I compiled gcc on an Ubuntu machine and installed it into a prefix, then copied the prefix folder to the SUSE machine. When I tried to run it gcc complained about not finding GLIBC_2_14, so I downloaded an rpm for libc6 online and included it into the prefix folders. my LD_LIBRARY_PATH includes prefix/lib and prefix/lib64. When I try to run any program now (ls, cp, cat, etc) I get the error error while loading shared libraries: /home/***/prefix/lib64/libc.so.6: unexpected reloc type 0x25.
Is there any way I can fix this so that I can get gcc4.9 up and running on this system?
As an alternative, is it possible to build gcc staticaly so that I don't have to worry about linking at all when I transfer it between computers?
my LD_LIBRARY_PATH includes prefix/lib and prefix/lib64
See this answer for explanation of why this can't work.
Is there any way I can fix this so that I can get gcc4.9 up and running on this system?
Your best bet is to install whatever GCC package comes with the SuSE system, then use that GCC to configure and install gcc-4.9 on it.
If for some reason you can't do that, this answer has some of the ways in which you can build gcc-4.9 on a newer system and have it still work on an older one.
is it possible to build gcc staticaly so that I don't have to worry about linking at all when I transfer it between computers?
Contrary to popular belief, fully-static binaries are generally less portable then dynamic ones on Linux.
I am trying to install the Vision Workbench on my computer, following the instructions from this homepage: http://lunokhod.org/?p=13. I have installed all dependencies but I have libboost1.54-all-dev instead since I am using Mint 17 (Ubuntu 14.4).
After that I have created the config.options file I do ./autogen and ./configure.
However, I get the following in the logfile:
configure:20861: /usr/include/boost is missing these required libraries: BOOST_PROGRAM_OPTIONS BOOST_FILESYSTEM BOOST_THREAD
Checking for a boost in /usr/include/boost-*
Checking for a boost in /usr/local/cuda/include
Checking for a boost in /usr/local/cuda/include/boost-*
configure:20875: checking for package BOOST
HAVE_PKG_BOOST=no
However, in /usr/include/boost/ I have booth program_options, filesystem and thread.
The .so files are under /usr/lib/x86_64-linux-gnu/ for opencv, boost and flann, but somehow it can only find flann.
Does anyone have an idea about where the error might be?
EDIT: In the log-file I saw that the program looked for cxcore when it searched for opencv, but in the new version it is called opencv_core so I did a symbolic link from cxcore to opencv_core and then ./configure finds opencv. However, boost is still a problem and is necessary to build the program.
EDIT2:
I have now downloaded an earlier version of boost (1.42), and almost all boost programs are found except BOOST_THREAD. When I install the boost library I get the following messages:
error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"
/ Erik
try running
./configure --with-boost="path/to/boost"
if you have more than one version of boost installed, you may need to also set environment variables
HAVE_PKG_BOOST=yes
PKG_BOOST_CPPFLAGS=/path/to/boost
PKG_BOOST_LDFLAGS=/path/to/boost
I am using Debian/MIPS+QEMU to build MIPS ports of PortFusion (a TCP tunneling solution). The resulting binaries are linked against GNU libc. Thus, they cannot be just copied over and used on vanilla OpenWrt which ships with uclibc instead of eglibc (which seems binary-compatible with GNU libc).
Is there a way to link Haskell/GHC binaries on Debian/MIPS against uclibc instead of eglibc?
Can OpenWrt's using uclibc be really the reason why PortFusion binaries copied over from Debian fail to run with -ash: binary not found or can this message be due to something entirely else?
See https://github.com/corsis/PortFusion/wiki/MIPS-Builds for details on which haskell-platform, Linux kernel and CPU emulation are used.
The current head of OpenWrt's GIT repository is failing at make when I attempt building custom OpenWrt images that use eglibc instead.
Is there a way to link Haskell/GHC binaries on Debian/MIPS against
uclibc instead of eglibc?
No. You need to to rebuild Haskell/GHC from sources using uclibc-based GCC cross-compiler.
Can OpenWrt's using uclibc be really the reason
Yes. Also, you can try to use ldd on your MIPS pplatform to check what library is missing. I'm sure it will be some of libc-related libraries.