I installed some encryption software called libntru.
The header files are installed in /usr/include/libntru and the file I would like to include from this directory is ntru.h. The compiled library is installed to /usr/lib/libntru.so.
In my makefile, I use gcc's -L and -l flags to link to the library as such -L/usr/lib -lntru, however in my project, I get a compiler error at the line #include <ntru.h>.
How can I link to this library? Thanks in advance for any help.
Check on the instructions with the software; there's at least a chance you're supposed to write one of:
#include <libntru/ntru.h>
#include "libntru/ntru.h"
If that's the case, you won't need to specify anything on the command line to find the headers (no -I option). If you're supposed to write just:
#include <ntru.h>
#include "ntru.h"
Then you need to add -I/usr/include/libntru to the command line.
Note that you probably don't need -L/usr/lib on the command line; the compiler will normally look there anyway, but you will need the -lntru option to specify the library itself, of course.
Related
In the process of trying to build some software AVL I'm getting some X11 library issues. I've done this install a few years ago and remember it being straight forward, but it was on an older version of OS el capitan I think and I'm on a "lite" version of Big Sur. I installed XQuartz and I can see the files it's expecting, but it seems to have trouble with the path to X11 per my understanding of this error
In file included from xwin11/Xwin2.c:74:
/usr/X11/include/X11/Xlib.h:44:10: fatal error: 'X11/X.h' file not found
In order for it to find Xlib.h I modified this (which I'm pretty sure isn't correct)
from
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/cursorfont.h>
to
#include </usr/X11/include/X11/Xlib.h>
#include </usr/X11/include/X11/Xutil.h>
#include </usr/X11/include/X11/cursorfont.h>
Before it would die on finding Xlib.h. It also seems to be ignoring the linking line I gave it in the config.make file
LINKLIB = -I/usr/X11/include -L/usr/X11/lib -lX11
Is there an environment variable or path I'm missing in my profile? Is it ignoring the linking flag. Or did I set this up incorrectly in the config file? What's really odd is that now it's finding Xlib.h but it can't find X.h and they live in the same folder, which really makes me think it just doesn't know where to find the X11 "stuff" .
Thanks!
Here's how to solve it:
determine from the compiler messages what include files the compiler cannot find
find them yourself
tell the compiler where they are
repeat above steps for libraries it cannot link
So, it cannot find Xlib.h. Let's find that:
find / -name Xlib.h 2>/dev/null
and, on my machine, I find:
/opt/X11/include/X11/Xlib.h
So that means I need to tell the compiler where to look for header files like this:
g++ -I /opt/X11/include ...
Then, when it encounters this in your code:
#include <X11/Xlib.h>
that means it will actually be expecting to find:
/opt/X11/include/X11/Xlib.h
Now, let's do the libraries:
find / -name libX11.dylib 2> /dev/null
and, on my machine, I find:
/opt/X11/lib/libX11.dylib
so that means I need:
g++ -I /opt/X11/include -L /opt/X11/lib/ ...
Thanks #MadScientist your comment was the key. I moved the
-I/usr/X11/include
out of the linking flag and into the compile flag and that solved it!
I have some C++ library code that I want strictly compiled for a quick check, and I don't want any files produced to be used for later stages (assembly, linkage, etc.)
I can do
g++ -S main.cpp
but this will give me an assembly file that I'm just going to wind up deleting anyway.
Is there an option that will tell the compiler to just compile a source file but don't produce any files?
EDIT[0]: I'm using mingw on Windows.
gcc has the option -fsyntax-only:
Check the code for syntax errors, but don’t do anything beyond that.
I'm really a Python developer exclusively, but I'm making my first foray into C programming now, and I'm having a lot of trouble getting started. I can't seem to get the hang of compilation and including libraries. At this point, I'm just identifying the libraries that I need and trying to compile them with a basic "hello, world" app just to make sure that I have my environment setup to do the actual programming.
This is a DBus backend application that will use GIO to connect to DBus.
#include <stdlib.h>
#include <gio/gio.h>
int
main (int argc, char *argv[])
{
printf("hello, world");
return 0;
}
Then, I try to compile:
~$ gcc main.c
main.c:2:21: fatal error: gio/gio.h: No such file or directory
#include <gio/gio.h>
I believe that I've installed the correct packages as indicated here, and gio.h exists at /usr/include/glib-2.0/gio/gio.h.
I found a command online to add a search directory to gcc, but that resulted in other errors:
~$ gcc -I /usr/include/glib-2.0/ main.c
In file included from /usr/include/glib-2.0/glib/galloca.h:34:0,
from /usr/include/glib-2.0/glib.h:32,
from /usr/include/glib-2.0/gobject/gbinding.h:30,
from /usr/include/glib-2.0/glib-object.h:25,
from /usr/include/glib-2.0/gio/gioenums.h:30,
from /usr/include/glib-2.0/gio/giotypes.h:30,
from /usr/include/glib-2.0/gio/gio.h:28,
from main.c:2:
/usr/include/glib-2.0/glib/gtypes.h:34:24: fatal error: glibconfig.h: No such file or directory
#include <glibconfig.h>
^
compilation terminated.
There has to be some relatively simple method for being able to set some options/variables (makefile?) to automatically include the necessary headers. I'm also going to use Eclipse-CDT or Anjuta as an IDE and would appreciate help to fix the import path (or whatever it's called in C).
Any help is greatly appreciated.
Use pkg-config (and make). See exactly this answer to a very similar question. See also this and that answers. Don't forget -Wall -g flags to gcc ..
You don't need an IDE to compile your code (the IDE will just run some gcc commands, so better know how to use them yourself).
On an almost default install of Ubuntu 11.04 I installed clang.
I am trying to compile this:
#include <cstdlib>
int main(){
return 0;
}
g++ can deal with it just fine, but clang++ errors out: fatal error: 'cstdlib' file not found
Can someone explain why this happens? and what needs to be done to make this work?
I expected clang++ to be a drop-on replacement for g++.
Seems like your clang build is not searching the correct platform include paths. Try checking with
clang -v ...
where it is looking for headers (and check that your platform include paths are there). You might have to add additional include directories (e.g. /usr/include/c++/x.y).
You might want to take a look at the source file lib/Frontend/InitHeaderSearch.cpp, The method AddDefaultCPlusPlusIncludePaths does some distribution/gcc-version specific magic (I had to fix it for my own system once).
I'm having a problem with my compiler telling me there is an 'undefined reference to' a function I want to use in a library. Let me share some info on the problem:
I'm cross compiling with gcc for C.
I am calling a library function which is accessed through an included header which includes another header, which contains the prototype.
I have included the headers directory using -I and i'm sure it's being found.
I'm first creating the .o files then linking them in a separate command.
So my thought is it might be the order in which I include the library files, but i'm not sure what is the correct way to order them. I tried with including the headers folder both before and after the .o file.
Some suggests would be great, and maybe and explanation of how the linker does its thing.
Thanks!
Response to answers
there is no .a library file, just .h and .c in the library, so -l isn't appropriate
my understanding of a library file is that it is just a collection of header and source files, but maybe it's a collection of .o files created from the source?!
there is no library object file being created, maybe there should be?? Yes seems I don't understand the difference between includes and libraries...i'll work on that :-)
Thanks for all the responses! I learned a lot about libraries. I'd like to put all the responses as the accepted answer :-)
Headers provide function declarations and function definitions. To allow the linker find the function's implementation (and get rid of the undefined reference) you need to ask the compiler driver (gcc) to link the specific library where the function resides using the -l flag. For instance, -lm will link the math library. A function's manual page typically specifies what library, if any, must be specified to find the function.
If the linker can't find a specified library you can add a library search path using the -L switch (for example, -L/usr/local/lib). You can also permanently affect the library path through the LIBRARY_PATH environment variable.
Here are some additional details to help you debug your problem. By convention the names of library files are prefixed with lib and (in their static form) have a .a extension. Thus, the statically linked version of the system's default math library (the one you link with -lm) typically resides in /usr/lib/libm.a. To see what symbols a given library defines you can run nm --defined-only on the library file. On my system, running the command on libm.a gives me output like the following.
e_atan2.o:
00000000 T atan2
e_asinf.o:
00000000 T asinf
e_asin.o:
00000000 T asin
To see the library path that your compiler uses and which libraries it loads by default you can invoke gcc with the -v option. Again on my system this gives the following output.
GNU assembler version 2.15 [FreeBSD] 2004-05-23 (i386-obrien-freebsd)
using BFD version 2.15 [FreeBSD] 2004-05-23
/usr/bin/ld -V -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /var/tmp//ccIxJczl.o -lgcc -lc
-lgcc /usr/lib/crtend.o /usr/lib/crtn.o
It sounds like you are not compiling the .c file in the library to produce a .o file. The linker would look for the prototype's implementation in the .o file produced by compiling the library
Does your build process compile the library .c file?
Why do you call it a "library" if it's actually just source code?
I fear you mixed the library and header concepts.
Let's say you have a library libmylib.a that contains the function myfunc() and a corresponding header mylib.h that defines its prototype. In your source file myapp.c you include the header, either directly or including another header that includes it. For example:
/* myapp.h
** Here I will include and define my stuff
*/
...
#include "mylib.h"
...
your source file looks like:
/* myapp.c
** Here is my real code
*/
...
#include "myapp.h"
...
/* Here I can use the function */
myfunc(3,"XYZ");
Now you can compile it to obtain myapp.o:
gcc -c -I../mylib/includes myapp.c
Note that the -I just tells gcc where the headers files are, they have nothing to do with the library itself!
Now you can link your application with the real library:
gcc -o myapp -L../mylib/libs myapp.o -lmylib
Note that the -L switch tells gcc where the library is, and the -l tells it to link your code to the library.
If you don't do this last step, you may encounter the problem you described.
There might be other more complex cases but from your question, I hope this would be enough to solve your problem.
Post your makefile, and the library function you are trying to call. Even simple gcc makefiles usually have a line like this:
LIBFLAGS =-lc -lpthread -lrt -lstdc++ -lShared -L../shared
In this case, it means link the standard C library, among others
I guess you have to add the path where the linker can find the libraray. In gcc/ld you can do this with -L and libraray with -l.
-Ldir, --library-path=dir
Search directory dir before standard
search directories (this option must
precede the -l option that searches
that directory).
-larch, --library=archive
Include the archive file arch in the
list of files to link.
Response to answers - there is no .a library file, just .h and .c in the library, so -l isn't approriate
Then you may have to create the libraray first?
gcc -c mylib.c -o mylib.o
ar rcs libmylib.a mylib.o
I have encountered this problem when building a program with a new version of gcc. The problem was fixed by calling gcc with the -std=gnu89 option. Apparently this was due to inline function declarations. I have found this solution at https://gcc.gnu.org/gcc-5/porting_to.html