libcap.so.2 missing while updating to GLIBC_2.29 - c

I had problem with GLIBC version while executing an exe file compiled in c.
/lib/x86_64-linux-gnu/libm.so.6: version 'GLIBC_2.29' not found
I found that I was using GLIBC_2.27. I updated to GLIBC_2.29 as mentioned the post
Once I installed GLIBC_2.29, I set the library path using patchelf command like below,
patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp
Now I got a new error,
error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
On checking for the file libcap.so.2 mentioned, I could see it is in the /lib/x86_64-linux-gnu/ path.
I am not sure how to set path for the libcap as I already set path to the glib.
Did I set the path in the wrong manner?. Is there anything I missed during the path setup in the above step?
NOTE : My Operating system is Ubuntu 18.01

I am not sure how to set path for the libcap as I already set path to the glib.
You can set multiple RUNPATHs like so:
patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 \
--set-rpath /path/to/newglibc:/lib myapp

Related

Accessing libnetlink.h

I'm trying to access some member variables within libnetlink.h, but when I #include in my source and compile with "gcc source.c -o binary", I get a "fatal error: libnetlink.h: No such file or directory" error.
I'm on Ubuntu 16.04 and I've already installed libnl-3-dev via apt-get install.
You need to put the correct path that must be seen from your source file.
this can be done by either:
1: Full path of the file 'libnetlink.h' like this (for example in linux):
/home/username/Desktop/folder1/libnetlink.h
2: Relative path of the file, corresponding to where your source file exist:
suppose your source file exist on 'Desktop', and your libnetlink.h exist in sub folder of Desktop folders called 'folder1', then the path will:
folder1/libnetlink.h
I guess the following command may help.
apt-get iproute-dev
I am using Fedora Core 26, after installing iproute-dev, the same problem is solved.

CMakeLists.txt configuration - simple but stuck - library not been added to generated project

I was originally following this tutorial: http://www.opengl-tutorial.org/miscellaneous/building-your-own-c-application/
just after about half way down, from where it says "Adding a source file in a project"
I created from this my CMakeLists.txt file as so:
cmake_minimum_required (VERSION 2.6)
project (Cube_Project)
find_package(OpenGL REQUIRED)
add_executable(Cube
main.cpp
)
include_directories(
external/glfw-2.7.6/include/
external/glm-0.9.4.0/
external/glew-1.9.0/include/
.
)
set(ALL_LIBS
${OPENGL_LIBRARY}
GLFW_276
GLEW_190
)
target_link_libraries(Cube
${ALL_LIBS}
)
but when I generate the project, I get this error:
ld: library not found for -lGLFW_276
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Any ideas?
I think maybe I'm not using the right names in the set(....) section? My three libs are in a folder called external, which is the top level of the project (i.e. CMakeLists is also here).
I put a zip of the project if anyone wants to take a look at the folder layout of output XCode project structure: http://heather.sh/OpenGL_Project.zip
Thanks,
The library is not in the linker's library search path.
The target_link_libraries command is is very straightforward: It simply passes on all of its arguments to the linker without bothering whether any of those libraries actually exist.
In your case, the GLFW_276 library is missing (and possibly the GLEW_190 as well, since the error occurs before that one is being processed). Make sure the library is actually installed on your system and its filename actually matches the name you use here (eg. libGLFW_276.so).
Once you verify that you have the required file, you need to make sure that the linker is able to find it. If the file is not located in one of the standard directories, use either link_directories to add its location to the search path, or find_library to obtain the full path to the library file, which can then be given to target_link_libraries.

How to correctly link libgit2 to C program using cmake?

First of all, i'm just a newbie in a CMake magic. And i just want to link libgit2 to my simple C program in CMake way (FindLibgit2.cmake).
As i understand from cmake documentation my CMakeLists.txt should looks like that:
project(libgit2test)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/")
# This variables should be setting up externally, i know - i show them just for example
set (LIBGIT2_LIBRARIES "<path to directory with git2.lib and git2.dll")
set (LIBGIT2_INCLUDE_DIR "<path to libgit2/include>")
find_package(Libgit2 REQUIRED)
include_directories(${LIBGIT2_INCLUDE_DIR})
set(LIBS ${LIBS} ${LIBGIT2_LIBRARIES})
target_link_libraries(${PROJECT_NAME} ${LIBS})
In my simple program i just call a couple of simple libgit2 functions and get this:
WARNING: Target "libgit2test" requests linking to directory "<libgit2 build directory>". Targets may link only to libraries. CMake is dropping the item.
I think the problem is here: target_link_libraries(${PROJECT_NAME} {$LIBS})
I try to change it to git2, but than i just get can not open file.
What i'm doing wrong?
P.S. I'm using Visual Studio 2010 compiler, Qt Creator to create CMake project, and successfully build libgit2 with CMake.
Remove
set (LIBGIT2_LIBRARIES "<path to directory with git2.lib and git2.dll")
set (LIBGIT2_INCLUDE_DIR "<path to libgit2/include>")
These variables should be set by find_package(Libgit2 REQUIRED).
I've found the source of problem: variable LIBGIT2_LIBRARIES must point to lib file itself, not the directory of it (debug/release).
However, setting up manually this variables looks like wired. I want to find more "automatic" way to find libgit2 - if one exists.

Netbeans EXE not working when executed from Terminal - CentOs

I made Netbeans work environment with SASL. The sample codes get build and it also run properly from Netbeans. But when I try to run my exe from Terminal it is not working. The error says as below:
./cppapplication_1: error while loading shared libraries:
libanonymous.so.2: cannot open shared object file: No such file or
directory
I tried setting the PATH using the below Command :
export PATH=/usr/lib64/sasl2/:$PATH
Still I am getting the same error. Do I need anything extra to do?
You need to add the path to libanonymous to the enviroment variable LD_LOAD_LIBRARY.
Update:
To do so:
Locate the library, for example doing: find / -name "libanonymous.so.2" or by locate libanonymous.so.2
Add the path found like so: export LD_LOAD_LIBRARY=$LD_LOAD_LIBRARY:<path to lib>
Update 1:
From your comment to Anon's answer I see that the lib in question is located under /usr/lib64/sasl2/.
So you might like to set LD_LOAD_LIBRAY path like so:
export LD_LOAD_LIBRARY=$LD_LOAD_LIBRARY:/usr/lib64/sasl2/
Update 2
This needs to be done in the same shell that later then executes the program needing the libraries (cppapplication_1).
cd <dir for cppapplication_1>; export LD_LOAD_LIBRARY=$LD_LOAD_LIBRARY:/usr/lib64/sasl2/; ./cppapplication_1
You can also try this.
ldd <name of executable>
You will see dependent libs and their expected paths. See if the lib is present at the path executable is expecting.

Installing a new library in Linux, and accessing it from my C code

I am working on a project which requires me to download and use this. Inside the downloaded folder, when extracted I am presented with three things:
A folder called "include"
A folder called "src"
A file called "Makefile"
After some research, I found out that I have to navigate to the directory which contains these files, and just type in the command make.
It seemed to install the library in my system. So I tried a sample bit of code which should use the library:
csp_conn_t * conn;
csp_packet_t * packet;
csp_socket_t * socket = csp_socket(0);
csp_bind(socket, PORT_4);
csp_listen(socket, MAX_CONNS_IN_Q);
while(1) {
conn = csp_accept(socket, TIMEOUT_MAX);
packet = csp_read(conn, TIMEOUT_NONE);
printf(ā€œ%S\r\nā€, packet->data);
csp_buffer_free(packet);
csp_close(conn);
}
That's all that was given for the sample server end of the code. So I decided to add these to the top:
#include <csp.h>
#include <csp_buffer.h>
#include <csp_config.h>
#include <csp_endian.h>
#include <csp_interface.h>
#include <csp_platorm.h>
Thinking I was on the right track, I tried to compile the code with gcc, but I was given this error:
csptest_server.c:1: fatal error: csp.h: No such file or directory
compilation terminated.
I thought I may not have installed the library correctly after all, but to make sure, I found out I could check by running this command, and getting this result:
find /usr -iname csp.h
/usr/src/linux-headers-2.6.35-28-generic/include/config/snd/sb16/csp.h
/usr/src/linux-headers-2.6.35-22-generic/include/config/snd/sb16/csp.h
So it seems like the csp.h is installed, maybe I am referencing it incorrectly in the header include line? Any insight? Thanks a lot.
The make command is probably only building the library, but not installing it. You could try sudo make install. This is the "common" method, but I recommend you to check the library's documentation, if any.
The sudo command is only necessary if you have no permissions to write the system's include and library directories, which may be your case.
Another possibility (instead of installing the library) is telling GCC the location of the library's source code and generated binaries (by means of the -I and -L options of the gcc command.
That Makefile will not install anything, just translate the source into a binary format.
The csp.h in the Linux kernel has nothing to do with your project, it's just a naming collision, likely to happen with three letter names.
In your case, I would presume you need to add the include directory to the compilation flags for your server, like gcc -I/path/to/csp/include/csp csptest_server.c.
(Next, you'll run into linker errors because you'll also want to specify -L/path/to/csp -lcsp so that the linker can find the binary code to link to.)

Resources