I want to create custom MIB and custom controller for this mib. I use Net-SNMP and Agent device is Debian based Linux machine that snmpd installed on it.I created template and generated .c and .h files using mib2c. At this point, I don't know what to do with these generated files? I want to handle some (The ones I created in MIB) SNMP request in my Clang application. So basically, if I copy the source that mib2c generated to my C project, will it work? Shouldn't I need to register these handlers to snmpd?
I followed this tutorial, but It focused on writing the code. It didn't mention compiling and executing.
After generating the .c and .h file you need to rebuild the netsnmp code again. To link your new .c and .h file into netsnmp, when you run the ./configure pass it as argument. (./configure --with-mib-modules="Object" where Object is the .c/.h filename). After that make using make command
Related
I have two executables that are build from the same source (a client and a server) and they're built with the compile options -D CLIENT=0 -D SERVER=1 for the server and -D CLIENT=1 -D SERVER=0 for the client. If I do something like
if (CLIENT) {
// Client specific code
}
clangd complains that CLIENT is not defined. Is there a way to make clangd aware of those macros? (The code compiles just fine, the errors are from clangd, not the compiler)
Is there a way to make clangd aware of those macros?
From getting started with clangd:
Project setup
To understand source code in your project, clangd needs to know the
build flags. (This is just a fact of life in C++, source files are not
self-contained.)
By default, clangd will assume that source code is built as clang
some_file.cc, and you’ll probably get spurious errors about missing
#included files, etc. There are a couple of ways to fix this.
compile_commands.json
compile_commands.json file provides compile commands for all source
files in the project. This file is usually generated by the build
system, or tools integrated with the build system. Clangd will look
for this file in the parent directories of the files you edit. Other
tools can also generate this file. See the compile_commands.json
specification.
compile_commands.json is typically generated with CMake build system, but more build systems try to generate it.
I would suggest moving your project to CMake, in the process you will learn this tool that will definitely help you in further C-ish development.
compile_flags.txt
If all files in a project use the same build flags, you can put those
flags, one flag per line, in compile_flags.txt in your source root.
Clangd will assume the compile command is clang $FLAGS some_file.cc.
Creating this file by hand is a reasonable place to start if your
project is quite simple.
If not moving to cmake, create a compile_flags.txt file with the content for example like the following, and clangd should pick this file up:
-DCLIENT=1
-DSERVER=1
I've been given these source files and headers. In the README.md the authors explain how to launch the test executables without the need of a proper installation. It is just a make command to run. They explain how to generate the .so files. I think these latter are meant to be used if I wanted to install the APIs at a system level (the definitions should be in api.h). My question is: where should I copy the shared objects generated by the Makefile and the api.h header? I aim to write a source file from scratch where I use those APIs (e.g. crypto_sign()) just including the headers, if it is possible. Thanks
where should I copy the shared objects generated by the Makefile and the api.h header? I aim to write a source file from scratch where I use those APIs (e.g. crypto_sign()) just including the headers, if it is possible
Nowhere.
The project comes with CMake support. Use CMake in your project and just add_subdirectory the repository directory.
Anyway, if you really wish to install the library system-wide, then FHS specifies directory structure on linux. For local system administration use /usr/local/lib for local libraries .so files and /usr/local/include for local C header files.
If I make headerfile.h and then headerfile.c with the source code for the functions. Once I compile the main C file sampleprogram.c
cc -o sampleprogram headerfile.c sampleprogram.c
Is that source file for the header still needed?
Is headerfile.c and sampleprogram.c compiled and linked together?
Do you need to include the headerfile.h along with sampleprogram if you were to put the program on a usb drive and put it on a different computer?
Headers are not required to execute a program or to use a shared/static library. However, headers are required to write code that uses the interface of a library. Usually, under RedHat distros, you'd have rpms that install the library (libuv) and rpms that install the headers (libuv-devel).
Therefore, without headers, you can execute a program, or you can link against a library. However, if you want to write code that uses the API of a library, you need the headers on your system.
If you compile a program and put it on a USB drive, all you need is the executable. However, you might need to recompile your program as the compiler targeted the specific architecture of the system it ran on. If you move the executable to another computer, it might not work.
Short answer:
No, it is not needed.
Longer answer:
No it is not needed, because when you use #include, the content of the header file will basically be pasted in to the C file. Because of that, the executable will not need the header file nor the c file to run (they are compiled into the executable already by the compiler)
I am trying to import a static library based on Hierarchical Matrices (H2Lib). The folder contains a make file which compiles the library files, examples and tests into a single .a file. I have referred to tutorials on creating and using static libraries in C using archiver command line in Linux but this does not create a header file, which I had to create manually while working out the tutorial. The H2Lib has multiple files and it would be difficult and time consuming to create a header file manually for this. I am not sure if I am missing something here or doing something wrong; I am new to the concept of libraries in C. Can some one please help me on how to use this library in C?
P.S: git repository link for H2Lib: https://github.com/H2Lib/H2Lib/tree/master
You are not supposed to write the header files yourself. Somewhere on the folder where the library is defined there should be a directory with multiple .h files (the headers) (it's usually named include).
What you need to do is include them into your project. You do this by appending -I to the path of each folder containing the headers and then writing #include "headername.h" in your source code.
So if the headers are in dir/include, you'd do:
gcc yourfiles.c <flags> output.o -I dir/include
I've just started to learn about linux kernel modules and the book I'm referring to says:
"For this [compilation] to work, the kernel source has to be suitably prepared; in particular it has to have a configuration file (.config in the main kernel source directory) and proper dependencies setup"
However, as far as I know (and have tried), the .config file is generated by the make menuconfig (or any of the equivalent make config commands) - and that doesn't seem to be enough for my module files to compile. What's the bare minimum I need to do in the kernel source directory?
make modules?
Yes, the .config file is generated using make *config.
Here are some of them:
make defconfig creates the default configuration for your architecture.
make config is the most primitive method, it prompts on every configuration.
make menuconfig is ncurses config menu. That's the one I prefer if I'm not editing .config file directly.
make gconfig is like menuconfig, but using gtk+.
Don't forget that make oldconfig should be called after modifying the .config file yourself.
Your current config might also be stored somewhere on your disk. For many linux versions, it's location is /boot/config-$(uname -r) If it exists, you can start with it. If not, your best bet is make defconfig, then editing the config file to suit your needs.
After configuration:
Before building modules, you might want to compile the kernel since your modules will not be used by the current kernel and even if you make your current kernel use those modules, it'll most probably cause a panic since symbol tables will not be in the order that your compiled modules assumes. make -jN is the most used method for compiling, N being twice your CPU core count. This also compiles modules, but creates .ko files for them, instead of embedding into the vmlinuz file.
After that, you can sudo make install to install your kernel. This usually wraps the kernel object you've just compiled into a suitable format and puts under /boot (it doesn't have to be /boot, actually).
Then you sudo make modules_install to copy the created .ko files into /lib/modules/$(uname -r). This builds all modules.
After doing that, you might prefer only building your own module, instead of all of them. When on the kernel tree root, you may make M=your_modules_relative_path to only build your module.
I don't know which book you're reading, but if you're building a module externally, you still have to perform the work above. After that, you may use LDD examples as a starting point for your makefiles.
See https://github.com/duxing2007/ldd3-examples-3.x