I'm trying to compile a C source code, generated with flex.
The gcc compiler tells me that it can't find the def.h library.
I have defined this library in the lex code with:
#include "def.h"
(I've taken the lex source code from a book)
Where is the problem?!
(Question answered in a comment: Question with no answers, but issue solved in the comments (or extended in chat) )
#Brian Olivier wrote:
def.h is not part flex. I would assume the book has a definition of def.h and a def.c``. If you don't get any other errors, you may try to just leave out the #include "def.h".
OP Confirmed:
That file was defined many pages before, and it was explicitly declared like a user header file only once.
Related
The company I'm working for does not use Doxygen, and in their coding standard explicitly prohibits "parseable comment styles such as javadoc, etc".
However, I've still found it very useful to run Doxygen myself just so I can see the class structure, and get nice per-class documentation of all the methods the a class has, including inherited ones.
The company does document the classes in the header files, with simple comments above each method declaration. It would be very useful if I could configure Doxygen to treat these comments as the function descriptions, even though they don't start with any Doxygen markers.
So: is it possible to get Doxygen to treat comments on the line above declarations as if they are the description for that item even when the comment is not marked with Doxygen's "parse this comment" markers?
The next best thing is to click on the #include <foo.h> links at the top of the class file to jump to the file itself, which I have been using. That doesn't help for seeing all of a derived class's methods in one place, though.
When the comments above the methods have only "normal" comments i.e. with /* or // the best thing to do would be that you write a small filter (see e.g. INPUT_FILTER with sed or awk or ... ) in which you convert (all?) /* / // comments into /** / /// so the comment blocks are parsed by doxygen. The result is not as nice as with "full" doxygen comments.
It is just a workaround and can lead to unexpected results when the INPUT_FILTER does not exclude e.g. // inside strings from consideration.
I've just started using doxygen to document some legacy C code and I'm very impressed about what in can do even with un-marked up code. I've gotten the basics, annotating routines: brief, description, param, return, see, etc. That all appears (beautifully) in the generated documentation for the function. My question is: Can I put doxygen markup inside the routine, interspersed in the actual code, so comments that explain the "upcoming" section of code, can also be included in the documentation. Providing a stepwise overview of what the function does without having to copy those comments to the top of the routine?
It's about the stm32 question ,now I want to compile the program about receiving and sending data through gpio in keils .when I build it ,there are always having some warning about
#223-D: function "usart1_send_byte" declared implicitly or #223-D:
function "usart1_send_byte" declared implicitly
I don't know how to define it,please help me .
It is in a header file, probably something similar to stm32f1xx.h, depending on your board. ST has just released an online course through Udemy, very good for beginning the microcontroller journey if you plan to continue with ST chips. Sign up through my.st.com , the forum there is also quite useful.
If your code compiles/links and works correctly, you have the actual implementation of usart1_send_byte somewhere. Your compiler warns, but linker can still link because it is existing somewhere.
Do a file search for usart1_send_byte and find the header file which the function is defined. Then include that header file to the source file that this warning appears.
I have just one question related to Linux shared library files.
I saw lot of links related to dynamically shared library for the Linux O.S
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
Here in above link it is mentioned ---
include file for the library: ctest.h
Now in LINUX to use the libdl in build function --- dlopen, dlsym, dlclose.
Do we really need to include the prototype file -- ctest.h -- for dynamic lybrary ?
Please give some suggestion related to above post.
You don't really need to include the header or prototype file for the dynamic library, you do however need to at least the specific type information for the value returned by dlsym.
See here and here for examples that don't contain the include file for the dynamic library.
In the example you posted, they started off with their library functions not having header files / function prototypes, which along with providing instruction on how to avoid C++ name mangling is why they included the header file in this case.
If you define your own libraries without function prototypes, either in the source file or the header file, then you will need to include the header file when using dlsym, otherwise the inclusion of the header file of the dynamic library is unnecessary as its function prototypes were already included in the generated shared object.
The function prototypes included in header file are so that functions implemented can be resolved by name by linker. Where as the shared object file regardless of how it is linked, contains the implementation of the library which the linker links to.
The short explanation is that header files that are included with the #include are processed by the preprocessor, which means the resulting source file / files passed to the linker has knowledge of who each function call is because it looks up the function call prototype that was in the include file and has been included in the modified source. Include files tell the linker about who the function call is.
Object files, Shared Object files and other libraries files tell either the linker about what the implementation of the function call prototype does.
To answer your question in the comment, you will only have to add the libdl.so path to LD_LIBRARY_PATH or to /etc/ld.so.conf and run ldconfig, if that library or its relevant symlink hierarchy isn't in a standard location such as /usr/lib/ or /lib/.
See the following relevant StackOverflow answer answer for more information.
Further information can be found at
Program Library Howto
C Libraries Howto
Compilers, Assemblers, Linkers, Loaders: A Short Course
Linkers and Loaders
Beginner's Guide to Linkers
This is probably a totally noob question but I have missing links in my mind when thinking about linking libraries in iOS. I usually just add a new library that's been cross compiled and set the build and linker paths without really know what I'm doing. I'm hoping someone can help me fill in some gaps.
Let's take the OpenCV library for instance. I have this totally working btw because of a really well written tutorial( http://niw.at/articles/2009/03/14/using-opencv-on-iphone/en ), but I'm just wanting to know what is exactly going on.
What I'm thinking is happening is that when I build OpenCV for iOS is that your creating object code that gets placed in the .a files. This object code is just the implementation files( .m ) compiled. One reason you would want to do this is to make it hard to see the source code and so that you don't have to compile that source code every time.
The .h files won't be put in the library ( .a ). You include the .h in your source files and these header files communicate with the object code library ( .a ) in some way.
You also have to include the header files for your library in the Build Path and the Library itself in the Linker Path.
So, is the way I view linking libraries correct? If , not can someone correct me on this ?
Basically, you are correct.
Compiling the source code of a library produces one object file for each of the source files (in more than one, if compiled multiply times against different architectures). Then all the object files are archived (or packaged) into one .a file (or .lib on Windows). The code is not yet linked at this stage.
The .h files provide an interface for the functionality exposed by the library. They contain constants, function prototypes, possibly global declarations (e.g. extern int bad_global;), etc. -- basically, everything that is required to compile the code which is using the library.
.h files do not 'communicate' with object code in any way. They simply provide clues for the compiler. Consider this header file:
// library.h
extern int bad_global;
int public_func(int, const void*);
By including this file in your own code, you're simply telling the compiler to copy and paste these declarations into your source file. You could have written declarations for OpenCV library and not use the headers provided with it. In other words, you're asking the compiler to not issue errors about undefined symbols, saying "I have those symbols elsewhere, ok? Here are their declarations, now leave me alone!".
The header files need to be included in the search path in order for compiler to find them. You could simply include them via the full path, e.g. #include "path/to/file.h", or supply an -I option for your compiler, telling him where to look for additional headers, and use #include <file.h> instead.
When your code is compiled, the declarations in header files serve as an indication that symbols your code is using are defined somewhere. Note the difference between the words declaration and definition. Header files contain only declarations most of the time.
Now, when your code is compiled, it must be linked in order to produce the final executable. This is where the actual object code stored in the library comes into play. The linker will look at each symbol, function call, etc. in your object code and then try to find the corresponding definition for each such symbol. If it doesn't find one in the object code of your program, it will look the standard library and any other library you've provided it with.
Thus, it is important to understand that compilation and linkage are two separate stages. You could write any function prototypes at all and use them in your code, it will compile cleanly. However, when it comes to the linking stage, you have to provide implementation for symbols used in your code, or you won't get your executable.
Hope that makes sense!
The .a is the compiled version of the code.
The header files provided with a library are its public interface. They show what classes, methods, properties are available. They do not "communicate" with the binary code.
The compiler needs the headers to know that a symbol (a method name for example) is defined somewhere else. They are associated with the right "piece of code" in the library binary later during the "link" step.