What is the header file for vsnprintf in the kernel? Can anyone please tell me this, I have kernel 5.14 and I am not sure what headers are default on my system. I have a number of different kernel headers installed, these are:
linux-headers-5.11.0-25
linux-headers-5.11.0-40
linux-headers-5.11.0-25-generic
linux-headers-5.11.0-40-generic
linux-headers-5.11.0-38
linux-headers-5.11.0-38-generic
Which one should be the default? But i like to ask what is the header file for function vsnprintf?
Taking a look at the source code for Linux v5.11, the correct header seems to be linux/kernel.h. It's the same file for Linux v5.14.
To check which headers you should use for your currently running kernel use the command uname -r which should tell you the correct version. You can then compile using those and an appropriate Makefile: see the documentation for more info.
Related
I'm cross compiling on Windows 7 and I use this compiler:
gcc-linaro-arm-linux-gnueabihf-4.7-2013.03\bin\arm-linux-gnueabihf-g++.exe
I want to use libcurl for some HTTP requests but when I link using -libcurl I get the infamous message that the linker couldn't find that library. I tried searching on the internet for the correct library for this architecture (ARMHF) but I can't find anything. Or maybe I did find it but I'm doing things wrong? My linking call is long but here it is:
This is the one that works, if I add -libcurl or anything related it breaks...
C:\vde\toolchains\windows\vos2\gcc-linaro-arm-linux-gnueabihf-4.7-2013.03\bin\arm-linux-gnueabihf-g++.exe -o out\RefApp -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\lib -Wl,-r
path=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\lib -Wl,-rpath=C:\vde\SDKs\vos2\vos2-sdk-winx86-release-3101
0800\vos2\usr\local\lib\svcmgr C:\desarrollo\corvet\out\corvet.a -LC:\desarrollo\RefApp\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-re
lease-31010800\vos2\lib -LC:\vde\SDKs\vos2\vos2-sdk-winx86-release-31010800\vos2\usr\local\lib\svcmgr -LC:\vde\ADKs\adk-full-4.6.5-610\vos2\lib -L -LC:\desarrollo\corvet\out -lrt -llog -lvfiguiprt -l
vfiipc -lTLV_Util -lpthread -lvfiplatforminfo -lsvc_utility -lvfibuzzer -lsvc_powermngt -lsvc_led -lvfisysinfo -lvfisysbar -lsqlite -lexpat -linf -lcom -levt -ltecclient -lmsrclient -lEMV_CT_Link -lEM
V_CT_Client -lEMV_CTLS_Link -lEMV_CTLS_Client -lNFC_Framework -lNFC_Client -lsvc_tms -lUtils -lseccmd-static -lsvc_sound -lccp -lcrypto -lsec -lseccmd-static -lsecins -lvfisvc -lvfisyspm -lvfimac -lvf
isec -lAdkCapX
I also tried downloading some libcurl libraries I found on debian page and that were supposedly for ARMHF, put them in some folder and used -L(routetofolder) but that didn't work either.
Hope you guys can help me out.
Thanks!
Well, libcurl is there in what you get from the vendor (if you look at /usr/lib you will find it there). It's a problem with your linking.
You might want to try looking at how dynamic libraries dependencies are resolved at linking and later at runtime on linux systems. It will also help you understand what may be happening on vos2 platform when you will try using your own dynamic libraries that may have conflicting names and linker can resolve them to something existing on the same device but at a location that you might not have permissions to read, because it belongs to different usrXX or sysXX.
Reading /etc/ld.so.conf from the device will help you understand the locations and search order done by dynamic linker. You can get the file from the device or simply find it in OS.rfsbundle (look in skeletonfs) and set your linking options right. I think it's not normally distributed with sysroot by the vendor but you can manually add it.
I wanted to debug printf function, so when I step inside the printf function (gdb debugger) it showed me this:
__printf (format=0x80484d0 " my name is Adam") at printf.c:28
28 printf.c: No such file or directory.
What is the meaning of this?
And when I again started step then there are a lot more statements like this.
Please help me to understand this.
I think it's pretty clear. There is a place where the gdb expects the source code to be, so download glibc's source code and put it there. I think the error message contains the full path.
If it's a linux distro it's fairly simple in fact because usually source packages are shipped too. Otherwise you need to find the source code yourself, note that it MUST be exactly the same that was used to compile the c library components, not just the same version because distributors often make changes to the sources.
Well, for the debugger to show you the code that was compiled into the binaries you're using, you need the original code somewhere.
You don't seem to have that, so your debugger can't find it.
Notice that you usually do not want to debug the source code of your std library functions, but only the way they are being called. For that, the usual "debug symbol" packages of your operating systems are optimal.
As others have answered, GDB was unable to find the source file.
For the C runtime libraries, Linux distributions may provide a debuginfo RPM that you can install, which may allow GDB to view the files. For example:
$ yum search glibc-debuginfo
...
glibc-debuginfo.x86_64 : Debug information for package glibc
glibc-debuginfo-common.x86_64 : Debug information for package glibc
...
The glibc package and the glibc-debuginfo are a matched pair. There is no explicit dependency, but glibc-debuginfo package won't work unless it is matched with the same version of glibc.
If you have the sources unpacked somewhere, but not where GDB is expecting them to be, you can attempt to use either the directory or the set substitute-path command to let GDB know where the sources are.
The directory command tells GDB to prepend a prefix ahead of any source file path it is attempting to find. For example, if the source tree is actually located under the /tmp, you could use:
(gdb) directory /tmp
The set substitute-path command is used to tell GDB to replace a matching prefix in a source file path with a different path prefix. For example, if the compiled source file was in /build/path/source.c, but in debugging the source file is actually in /usr/home/alice/release-1.1/source.c, then you could use:
(gdb) set substitute-path /build/path /usr/home/alice/release-1.1
The command assumes that you are only specifying a complete path names, so it won't perform the substitution on /build/pathological/source.c.
EDIT: NEVERMIND - I had already successfully fixed this problem by putting a copy of the header where the compiler would find it. However, other build errors in cmake-gui kept referring me to the old error log file with the old build error, making me falsely believe I had not solved the problem.
I will close this question once the seven day bounty period is expired.
I am attempting to create a Windows port of a Linux library that uses pthreads via pthreads-win32, but I am having issues telling CMAKE where to locate pthreads.h. Does anyone know how to direct CMAKE to look to a specific location for pthreads.h? And also for the library file?
Alternately, is there some sort of magical global include directory I could use?
For example , in CMakeLists.txt , you can use INCLUDE_DIRECTORIES to include the path .
INCLUDE_DIRECTORIES([AFTER|BEFORE] [SYSTEM] dir1 dir2 ...)
and you can add the link path of pthread.h with this when you want to link the library :
LINK_DIRECTORIES(directory1 directory2 ...)
TARGET_LINK_LIBRARIES(target library1<debug | optimized> library2...)
In here , it say that you can link with libwinpthread.a
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.)
I am running Ubuntu 10.10 on an IBM R51 machine. When I access list.h to read it(manually/humanly) I open /usr/src/linux-headers-2.6.35-22/include/linux .
But when coding a C program in terminal, I cant invoke any #include because it is not in the default /usr/include folders.
When I change the statement to reflect the path by typing #include "/usr/src/linux-headers-2.6.35-22/include/linux/list.h" it returns errors as list.h in turn calls other header files which are mentioned as located in "linux" folder
The header files are as you must be aware:
"linux/poison.h", "linux/prefetch.h" and "asm/system.h"
So if I have to copy each, I can but prefetch in turn calls other dependencies, which are not present in /usr/include directory. I hope you understand.
How can I solve this problem?
Are you sure these headers are really what you need ? The standard C headers should be under /usr/include
Anyhow you need to pass the header search path to the compiler via the '-I' flag.
Pass the path via -I
-I/usr/src/linux-headers-2.6.35-22/include/linux
Then in your C code
#include "list.h"
Link to GCC manual & preprocessor directives
The header files you are using are designed for internal use of the Linux kernel. They were not designed to be used by a userland program.
If you MUST use these headers (the Linux kernel list implementation is brilliant), copy the headers into your program source directory. Copy each file that is referenced, edit each one to remove whatever assumptions exist about being used in-kernel, and recurse until you're finished. I might suggest to make your own prefetch() macro that simply does nothing, rather than try to untangle <linux/prefetch.h>. Do the same for <linux/poison.h>, and untangle <linux/types> and <linux/stddef.h> (not too hard here :) as best you can.
And also be sure you license your project GPLv2 (and specifically GPLv2, the Linux kernel's COPYING file is quite strict that GPLv2 is the only license that applies; there is debate whether the GPL allows specifying only one version, but that is the license Linus chose ages ago, and the license that is valid on all files unless specified otherwise).
adding -I/usr/src/linux is a no-go, since unsanitized header files are not meant to be used from user programs
you could manually copy list.h to your own project and sanitize
or use a library that is specifically for userspace and provides the same functionality (since you already used libHX elsewhere, you might want to continue reading into the linked list chapter)