This is my current workspace. I have the Headers in the same folder with the otp.c but whenever I compile and run it it returns an error telling me that hmac-sha1 is undefined. Hope someone can help me.
Short Background
Including a header file enables you to compile the source file into an object file by declaring the function.
However, to get an executable, you need to link the object files together whereby one function used in one object file may be defined (i.e. implemented) in another object file. When listing the objects for the linker, they must be arranged in order of dependency, e.g if a depends on b the a should appear before b on the command line (in case of circular dependencies please find a post on it).
Solution
The way you run gcc makes it first compile the sources into object files and link them. otp.c requires the function hmac_sha1 is probably in hmac-sha1.c (I am guessing from the header file name) and so you should run:
gcc otp.c hmac-sha1.c -o otp
Note that otp.c depends on hmac-sha1.c hence the order.
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"))
I want to compile the sqlite amalgamation to create a database which is protected by a password via user authentication.
I followed this tutorial: https://www.sqlite.org/howtocompile.html
And also the documentation by SQLite for the user_authentication: https://www.sqlite.org/src/doc/trunk/ext/userauth/user-auth.txt
When I try to compile it without the extra compile-time option "-DSQLITE_USER_AUTHENTICATION" and without adding the other documents it works. When I try to compile it with I get the error C2129 at sqlite.c and error C1083 at userauth.c
In this directory are the following files:
shell.c
sqlite3.c
sqlite3.h
sqlite3ext.h
sqlite3userauth.h
userauth.c
cl -DSQLITE_USER_AUTHENTICATION shell.c sqlite3.c userauth.c -Fesqlite3.exe
Following output:
shell.c
sqlite3.c
sqlite3.c(222878): error C2129: static function 'void sqlite3CryptFunc(sqlite3_context *,int,sqlite3_value **)' declared but not defined
sqlite3.c(16263): note: see declaration of 'sqlite3CryptFunc'
userauth.c
userauth.c(26): fatal error C1083: Cannot open include file: 'sqliteInt.h': No such file or directory
Generating Code...
In case there is something like C#'s db.SetPassword("MyPW") available in c, that would be perfect!
I followed [...] the documentation by SQLite for the user_authentication: https://www.sqlite.org/src/doc/trunk/ext/userauth/user-auth.txt
Well no, it doesn't look like you did. Those docs say
Activate the user authentication logic by including the
ext/userauth/userauth.c source code file in the build and adding the
-DSQLITE_USER_AUTHENTICATION compile-time option. The ext/userauth/sqlite3userauth.h header file is available to
applications to define the interface.
When using the SQLite amalgamation, it is sufficient to append the
ext/userauth/userauth.c source file onto the end of the amalgamation.
You are using the amalgamation, so you should append [the contents of] userauth.c to the amalgamation. That is, copy its contents to the end of sqlite3.c. From your directory listing and command line, it appears that you are instead attempting to build it as a separate source file, to be linked to the main one at the end. That's not equivalent, and in particular, it differs with respect to the effect on the scope of static functions and variables, which is exactly what your compiler is complaining about.
It's unclear whether -DSQLITE_USER_AUTHENTICATION should also be used with the amalgamation. A literal reading of the SQLite docs suggests not, but I would be inclined to guess that it actually is required either way if you want to enable the feature.
The error about the missing header is a little concerning, and it is possible that you will see it again. If you do, it may be sufficient to simply remove or comment out the corresponding #include directive, as all the needed declarations from that header, which is among the main sources, should already be included in the amalgamation.
anyone can help me?? my board is LPC1768 and the sensor is BMP180
Rebuild target 'Target 1'
compiling BMP180.c...
compiling I2C.c...
assembling startup_LPC17xx.s...
compiling system_LPC17xx.c...
compiling GPIO_LPC17xx.c...
compiling PIN_LPC17xx.c...
linking...
.\Objects\asdsa.axf: Error: L6218E: Undefined symbol main (referred from __rtentry2.o).
Not enough information to list image symbols.
Finished: 1 information, 0 warning and 1 error messages.
".\Objects\asdsa.axf" - 1 Error(s), 0 Warning(s).
Target not created.
I found the solution is easy, but before going deeper into the solution, keep in mind that C compilation unit (C Compiler and Assembler at least) compiles each pure C source file after resolving necessary pre-processor directives, and generates a relocatable object file as a result of compilation.
After the compilation unit does its job, there is another unit that is responsible for combining individually every source file that is compiled successfully into the relocatable form of one big object file for all. This unit is called Linker and the operation is called Linking
A very important feature in relocatable object file is that what is called variable, function will be noted as symbol so far. The linker has to solve the symbols, defining what is originally defined in an object file, reference what is being used in another to their original object file.
After this motivation, now we can call main() function as main() symbol.
I Found that the problem is because the source file that contains the main() function was not compiled. As a result, there is no a relocatable object file that contains the symbol corresponding to main() function. Hence, the compiler is complaining: you asked me to use (reference) a symbol you guaranteed to be found (defined) in another file but I found no such symbol!
The solution:
For Kiel IDE, to queue a source file for a compilation; you gotta shortlist it in the category "Source Group",by clicking right, either adding new files to group, or existing files to group. It will result in something like the following figure:
Now we have a main function, is turned (defined) to main symbol later, and found by the linker to reference it to whatever use it in any other relocatable object files.
I solved this problem with the following steps;
Delete your old project and create new project
Choose true library from Manage Run Time Environment like so:
Configure "Options for Target" segment. Define symbol USE_STDPERIPH_DRIVER and define project path like so:
Test your configuration. Please write the following code:
#include "stm32f10x.h" // Device header
int main() {
}
I had the same issue. The problem was that the function name in .c file had a different name with the one in the .h file, and I didn't know.
just add your c file (ex: 'main.c') to the source group (ex: 'source group 1') by expanding the target then right click on the source group, choose add existing files to group 'your source group', then choose the main.c file.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/14222.html
This should help.
Just create a dummy main() or main.c file. Linker can't find it in your pjt.
For solution only add this file C to driver folder and translate it,
Solved: This "Target Not Created" Issue was Resolved by the setting of Run Time Environment as shown in below(url) image.https://i.stack.imgur.com/kJ4IL.jpg ( consisting of CMSIS and Device supporting components in Run time environment)
{ compiling TransformFunctions.c...
linking...
Program Size: Code=768 RO-data=320 RW-data=4 ZI-data=612
FromELF: creating hex file...
".\Objects\LPC1768_B_T.axf" - 0 Error(s), 0 Warning(s).
Build Time Elapsed: 00:00:07
}
I've taken the plunge and am learning C. It's been a pretty good but manageable learning curve coming from a scripting (php, perl) background with only a little bit of C#.
I've used the web-site "Learn C The Hard Way" and am so far grasping reasonably well (I think) but I can't understand this part of one of the exercises:
http://c.learncodethehardway.org/book/ex19.html
He created four source files - object.h, object.c, ex19.h, ex19.c
But I don't understand how the object.c file is included.
The main function is located in ex19.c, and it has the line
#include "ex19.h"
File ex19.h has the line
#include "object.h"
But object.h makes no reference to including object.c. Interestingly object.c contains the line
#include "object.h"
Is there some sort of implied include where if you include the header file, it will automatically include the c source code of the same name?
This is the job of a separate program called the linker. In C, source files need access to the header files of other C source files so that they can see information about what functions, types, and variables are defined by that second C file that the first file might want to use. Each C file is then compiled independently of the rest. The output of the compiler is an object file.
To build a final program, a second program called the linker comes in and combines all the object files together into the overall executable. This program is tasked with taking the implementations of all the different C files and cross-referencing them against one another so that each time one C file references a function or variable in a different C file, that reference can actually be made to the appropriate object.
This is why you don't need to include .c files. Once a source file has a header, it knows enough about the other file in order to use the functions it provides for the compiler to verify that it's using them correctly. The linker then handles of the job of actually making the cross-references. You can think of the compiler as a program that checks to see that if the functions are defined, then the program would work. The linker then actually checks to make sure that those functions are defined in the first place and sets up the appropriate links in the executable.
Hope this helps!
Object.c is not included.
It's compiled as it's own unit and it includes object.h
See the make file:
CFLAGS=-Wall -g
all: ex19
ex19: object.o
clean:
rm -f ex19
ex19: object.o tells you that object.o must be created before ex19 can be built, and this is picked up by default from make file as an object.c exists.
So this make file says
to build all you need ex19, to get ex19 you need object.o, and the to create object.o the makefile picks up object.o built from the object.c
From the page you reference:
make can't see anything in the file for object.o, but it does see an
object.c file, and it knows how to turn a .c into a .o, so it does
that.
The entire logic lies in the makefile and an intelligent compiler. The final binary created has an object file named as object.o which will ideally contain all the function definitions defined in object.h file. It is the linker which links the functions declared in .h file with the definition which are available in .o file.
I'm pretty new to working with libraries and I'm in the process of trying to understand some specifics regarding static libraries and object files.
Summary
The behavior I'm noticing is that I can link several objects to make an executable with no problem, but if I take an intermediate step of combining those objects into static libraries, I cannot link those static libraries to make an executable without additionally specifying the needed C Run-time library in the link command.
Also, or the record, I'm doing the compiling/linking with Visual Studio 2010 from the command line. More details of the process I'm following are below.
First, let's say I have four source files in a project: main.c, util1.c, util2.c, and util3.c.
What works
I can compile these sources with the following command:cl -c main.c util1.c util2.c util3.cAs a result, I now have four object files: main.obj, util1.obj, util2.obj, and util3.obj. These object files each contain a DEFAULTLIB statement intended to inform the linker that it should additionally check the static C Run-time library libcmt.lib for any unresolved external dependencies in these object files when linking them.
I can create an executable named "app_objs.exe" by linking these objects with the following command:
link -out:app_objs.exe main.obj util1.obj util2.obj util3.obj
As mentioned in step 1, the linker used the runtime library due to the compiler's step of adding a default library statement to the objects.
Where I'm confused
Let's say I want to have an intermediate step of combining these objects into static libraries, and then linking those resulting LIB files to create my executable. First, I can create these libraries with the following commands:
link -lib -out:main.lib main.obj
link -lib -out:util.lib util1.obj util2.obj util3.obj
Now, my original thought was that I could simply link these libraries and have the same executable that I created in step 2 of "What works". I tried the following command and received linker error LNK1561, which states that an entry point needs to be specified:
link -out:app_libs.exe main.lib util.lib
From Microsoft's documentation, it is evident that linking libraries without any object files may require entry points to be specified, so I modified the command to set the subsystem as "console" to specify that the executable in intended to be a console application (which seems to imply certain entry points, thereby resolving that error):link -out:app_libs.exe -subsystem:console main.lib util.libUnfortunately, now I get a linker error stating that mainCRTStartup is an unresolved external symbol. I understand that this is defined in the C runtime library, so I can resolve this issue by manually specifying that I want to link against libcmt.lib, and this gives me a functioning executable:link -out:app_libs.exe -subsystem:console main.lib util.lib libcmt.lib
What I'm not understanding is why the default library info that the compiler placed in each object file couldn't be used to resolve the dependency on libcmt.lib. If I can link object files without explicitly stating I want libcmt.lib, and I created static libraries that are containers for the object files, why can't I link those static libraries without having to explicitly state that I want libcmt.lib? Is this just the way things are, or is there some way I could create the static libraries so that the linker will know to check for unresolved symbols in the runtime library?
Thanks for your help. If I have some fundamentally incorrect ideas here, I'd love suggestions on good references to learn all of this correctly.
Well the answer to your misunderstanding is that .lib files are often a product in themselves, and the compiler can't make those assumptions safely. That's what "external" is for.
If I produce binaries for someone's platform because its users are totally helpless, and they want/need static linkage, I have to give them foo.h and libfoo.lib without tying them to a specific runtime entry point. They may very well have defined their own entry point already for their final product, whether DLL or EXE.
You either want the runtime, or you want your own .obj that contains your entry point. Be warned that declaring and defining mainCRTStartup on your own may mean you're not executing important instructions for the target platform.