I'm trying to build the linux kernel and would like to understand a few things:
I have added a new file (b.c) to a certain directory with the intention of having the file compiled in. The Makefile has been updated accordingly. While compiling the file, an error is thrown saying that a certain header (a.h) is not found. However, other files in the same directory use a.h without any issues.
I have observed that .o.cmd file get created for all files except b.c. Is this a prerequisite for the headers to be correctly included? Does this file have any significance to the issue I'm facing?
For eg: I added 'async_infra.o' to this line in the Makefile:
uml_gre-objs := uml_gre_kern.o uml_gre_user.o async_infra.o
uml_gre_user.c includes the header that I'd like to be included in async_infra.c
Any suggestions on what's missing and how to address the issue will be appreciated.
Related
I have an existing .so library (libgit2), and I would like to use this within a C program (the build system is Scons). I read through the entirety of the Scons documentation for "Chapter 4. Building and Linking with Libraries", but there is no mention of how to use an existing .so library. The only mention of .so in the entirety of chapter 4 is on the first page, and it is only about Scons using a .so file for output. How do I use an existing compiled .so library in Scons?
If you are using an sconscript then you should add a LIBS= arguments and a LIBS_PATH=.
if you want to directly add it to the build line, use -L for lib path and -l to link a lib.
You can find further information here: https://scons.org/doc/0.97/HTML/scons-user/x628.html
With help from the SCons Discord server and other places, I've gotten farther than when I first posted this question. I haven't solved my specific problem of using .so libraries with GDNative, but I think I've figured out the SCons side.
As of me posting this question, the SConstruct file was able to compile working code if I didn't use libgit2 and instead just printed out the text. With only the header included, my test call to git_libgit2_version compiled but didn't run, as Godot said undefined symbol: git_libgit2_version.
First of all, you need to add the named parameter for LIBS to your env.SharedLibrary or env.Program line. The lib prefix and .so suffix seem to be added automatically, I still haven't figured out how to make it point to libgit2.so.1.0.1 (so for now I have the library copied and named as libgit2.so, but I would like to have it point to libgit2.so.1.0.1 eventually instead). Also, the SCons team suggested adding LIBPATH, but this doesn't seem to actually do anything.
library = env.SharedLibrary(target=env["target_path"] + env["target_name"] , source=sources, LIBS=['git2'])
Then, the SConstruct file needs to have this magic line:
env['STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME'] = 1
With the above code, ldd will report not found, and Godot will say Error: libgit2.so.1.0: cannot open shared object file: No such file or directory (I have no idea why it's asking for .so.1.0 instead of the .so or .so.1.0.1 file, and yes I tried copying and naming as libgit2.so.1.0 and that doesn't change anything either).
I also added this, which was suggested by another GDNative user.
env.Append(LINKFLAGS=[
'-Wl,-rpath,addons/git_for_godot/gdnative/linuxbsd'
])
With all of the above code, this seems to allow ldd and Godot to find the library just fine with a relative path (when running ldd you have to be cd'd into the project folder). I can run the project fine without any errors, but the project crashes immediately after opening, with no error messages printed. If I comment out the call to git_libgit2_version but keep the header included, the file does compile and run. Any time I try to call anything from libgit2 it causes Godot to crash without printing any errors. At this point I'm stuck and I don't know what I'm doing wrong.
I did try adding libgit2 to the Dependencies section of the .gdnlib file, but this doesn't seem to affect anything. Another thing I tried which didn't work is this line (+ variants on the extension) which append to the sources list passed as the named source parameter. I'll post it here for completeness, but for the moment I have this line commented out because it doesn't work:
sources.append(File("project/addons/git_for_godot/gdnative/linuxbsd/libgit2.so"))
Preface: I am very new to c and CLion, so apologies in advance if my phrasing is very wrong.
Essentially, I have an assignment that involves two c files (a "main", and one performing a conversion between imperial and metric units). The main c file simply #include-s the conversion file, performs a function within the conversion file, and prints the resulting value to the user. Simple enough, but I keep getting a message every time I try to run it:
"undefined reference to 'conversion'"
I have tried to suss out the problem, and my only idea relates to the banner at the top of conversion.c which says "This file does not belong to any project target, code insight features may not work properly.". I do not understand why I receive this message, because conversion.c and main.c are both within the main project directory, and this setup worked perfectly fine in my previous assignment.
I have searched for solutions online, and the only one that seemed to make sense was to update my CMakeLists.txt file to include add_executable(project conversion.c). This is what my CMakeLists.txt file looks like before I add this line:
cmake_minimum_required(VERSION 3.12)
project(project C)
set(CMAKE_C_STANDARD 11)
add_executable(project main.c)
However, when I add it, I get the error:
CMake Error at CMakeLists.txt:7 (add_executable):
add_executable cannot create target "directory" because another
target with the same name already exists. The existing target is an
executable created in source directory
"/home/john_s/CLionProjects/project". See documentation for
policy CMP0002 for more details.
Presumably this is because the previous line I have (add_executable(project main.c)) is linking to the same directory, but I have no idea how to resolve this. Any suggestions?
From cmake manual:
add_executable(< name> [WIN32] [MACOSX_BUNDLE]
[EXCLUDE_FROM_ALL]
[source1] [source2 ...])
Adds an executable target called to be built from the source files listed in the command invocation. (The source files can be omitted here if they are added later using target_sources().)
So to combile a single executable using two source files, you just use:
add_executable(target_name source1.c source2.c)
I am running the pc lint misra checks on my project.
When I execute the program the output is huge because it includes all the bsp files from arm. How do I get pc-lint to exclude a whole directory. In the code when I include a header file from outside the project I use <> instead of ""
i.e. #include <arm_driver.h>.
I thought this was enough. Is their another step missing?
These are the additional parameters I have passed
+libclass(angle, foreign)
-e686
-wlib(0)
And with the command vf I can see that all the external directory files are being treated as library headers.
Finally fixed the issue.
Comment out all the explicit +elib lines in the corresponding .lnt file.
i.e. replace all instances of +elib with //+elib
Imagine that I have a C-project in the following folder:
C:\microcontroller\stm32\myProject
I have two important folders inside myProject:
- source => here are all my .c and .h files
- build => gcc will write all the object files in here
Note: as you can see, the backward slashes indicate that this is happening on a Windows pc.
The figure below gives an overview:
I will not display my complete makefile here, because that would lead us too far. The rules inside the makefile for all .c => .o files are similar. Let us just focus on the compilation of one specific file: fileA2.c:
--------------------- COMPILATION OF FILE fileA2.c -------------------
Building ./build/folderA/fileA2.o
arm-none-eabi-gcc C:\\microcontroller\\stm32\\myProject\\source\\folderA\\fileA2.c
-o C:\\microcontroller\\stm32\\myProject\\build\\folderA\\fileA2.o
-c
-MMD
-mcpu=cortex-m7
-...
-IC:/microcontroller/stm32/myProject/source/folderA
-IC:/microcontroller/stm32/myProject/source/folderB
Notice that the gcc call ends with two include flags: one for folderA and one for folderB. This enables gcc to use any of the header files from these folders (fileA1.h, fileA2.h or fileB1.h) if fileA2.c has an import statement.
Let us now consider the source code in fileA2.c. We assume that this file needs to include fileA2.h and also fileB1.h.
/*******************************/
/* SOURCE CODE fileA2.c */
/*******************************/
// Some include statements
#include "fileA2.h"
#include "fileB1.h"
// Code
...
These include statements work perfectly. The gcc compiler retrieves the files fileA2.h and fileB1.h in the given folders. But I noticed that the following does not work:
/*******************************/
/* SOURCE CODE fileA2.c */
/*******************************/
// Some include statements
#include "fileA2.h"
#include "folderB/fileB1.h"
// Code
...
The last include statement is a 'partial path' to the file. I get the error when compiling:
fatal error: folderB/fileB1.h: No such file or directory
How can I get gcc to handle this?
PS: It is not my own habit to use 'partial paths'. But they appear a lot in the libraries from the silicon vendor of my chip, so I have to live with it.
You specify two paths to look for includes other than the current directory for the source file:
-IC:/microcontroller/stm32/myProject/source/folderA
-IC:/microcontroller/stm32/myProject/source/folderB
You get the error because neither
C:/microcontroller/stm32/myProject/source/folderA/folderB/fileB1.h nor
C:/microcontroller/stm32/myProject/source/folderB/folderB/fileB1.h exists.
To address the error, you can add the following path:
-IC:/microcontroller/stm32/myProject/source
When using double-quotes to include a header file the compiler first looks in the same directory as the current file. If the header file is not found then it continues with the standard include search paths.
So when the compiler compiles the file source/folderA/fileA2.c the first directory the compiler will look for include files is the source/folderA directory. In the first example the fileB1.h will not be found there, but since you added source/folderB to the standard search path it will be found there as source/folderB/fileB2.h.
In the second example there is no folderB/fileB1.h file on source/folderA so the compiler will search the standard search path. When it comes to source/folderB it will again try folderB/fileB2.h (i.e. source/folderB/folderB/fileB2.h) and it will still not be found, nor will it be found anywhere else.
You need to add -IC:/microcontroller/stm32/myProject/source to be able to find folderB/fileB1.h.
Apart of the two correct responses you have received before this, you have the third chance to specify the path to the file in the #include directive from the curren directory, as with
`#include "../folderB/fileB1.h"
Vim is pretty smart when it comes to C, so if one inserts a bogus header file such as #include <stdioo.h>, it complains by bringing up a location list with the following error:
foo.c:1|20| fatal error: stdioo.h: No such file or directory
|| compilation terminated.
Which is great, but for whatever reason, I get the same error when including the <mpi.h> header file. I know this is a vim problem b/c I can compile and execute the program with mpicc and mpiexec, respectively. Besides it being extremely irritating having it pop up every time I save the file, all syntax errors are ignored when this happens.
Is there any way to instruct vim to ignore this header file, or at least all the header files?
WHERE on your filesystem is the <mpi.h> file located?
Often it's one level down, such as /usr/include/mpi/mpi.h and would require <mpi/mpi.h> to access it.
You may need to add another directory path to the -I option list of your compiler, or add the directory path to VIM's path option variable
:help 'path
Will get you started on the VIM side, you'll need to look up how to add options to your current setup, no idea if you're using cmake, make, visual something, netclipse or whatever.
But a simple 'locate mpi.h' would be the place to start, since you know it's there.
You said "pop-up" ... are you using syntastic or such? Again, finding the proper path would help there too. Evidently mpicc knows the proper path to the include files, you just need to tell VIM. (via the 'path' option)