I am trying to use portaudio in one of my projects. Unfortunately, I cannot compile my main.c file.
Error: "undefined reference to 'Pa_Initialize'" (Pa_Initialize is a function from the portaudio library)
My working directory includes the .a file from portaudio as well as the portaudio.h.
My current gcc command: gcc main.c libportaudio.a -lm -o main
Update: these are the includes in my main.c
#include <stdio.h>
#include <math.h>
#include "portaudio.h"
If you get an undefined reference error, you have probably already integrated the header file portaudio.h.
As Kurt E. Clothier already mentioned, you must also mention the libraries inside your gcc command. According to the portaudio website, the gcc command is
gcc main.c libportaudio.a -lrt -lm -lasound -ljack -pthread -o main
I was able to fix the issue by rebuilding the portaudio library.
Related
I'm working on a big project with glfw but I have been stymied trying to link to a static library with gcc, hence this toy example. I'm not sure why I'm having so much trouble with such a simple thing.
This is the extent of my source code:
#include <stdio.h>
#include <ft2build.h>
#include FT_FREETYPE_H
int main(){
FT_Library ft;
if (FT_Init_FreeType(&ft))
{
printf("ERROR::FREETYPE: Could not init FreeType Library\n");
}
FT_Face face;
if (FT_New_Face(ft, "fonts/arial.ttf", 0, &face))
{
printf("ERROR::FREETYPE: Failed to load font\n");
}
return 0;
}
I'm running Linux Mint. I downloaded the FreeType library and built it using CMake and my version of GCC. The libfretype.a file is in a subdirectory called junk. The headers are in a subdirectory called include.
We compile it with the following:
gcc -Wall -Wextra -g -v -Iinclude -Ljunk vex.c -lfreetype -o vex
and I get a ton of errors like sfnt.c:(.text+0x218): undefined reference to 'png_get_error_ptr' .
Thanks in advance for telling me the silly mistake I made.
It basically means that the implementation of the function png_get_error_ptr is missing. So, the compiler could not generate an executable because some code is missing.
The function png_get_error_ptr is implemented in a library named libpng. Sometimes, some libraries have some dependencies on another project, in the general case, you need to include all the dependencies to your build to resolve the linker errors.
You need to include these libraries in the linker:
gcc -Wall -Wextra -g -v -Iinclude -Ljunk vex.c -lfreetype -lpng -lz -o vex
^ ^
-lz is to link against zlib because libpng rely on zlib if I remember correctly.
http://libpng.org/pub/png/libpng-manual.txt
I'm trying to make a static library (.a) but facing issues that I'm unable to understand. So in brief compiling with *.o succeeds but archiving them using ar and then using the .a file to compile gives me an undefined reference to 'symbol' error.
So here is a simple code.
test.c
#include <stdio.h>
#include <string.h>
int main()
{
hello_world();
return 0;
}
hello_world.c
#include<stdio.h>
void hello_world (void) {
printf("Hello World\n");
}
Compile.
gcc -c -o hello_world.o hello_world.c
ar crs libhello.a hello_world.o
gcc libhello.a -o test test.c
gives me the error
/tmp/ccsO7AJl.o: In function `main':
test.c:(.text+0xa): undefined reference to `hello_world'
Instead doing this works(Compiles and runs fine)
gcc -c -o hello_world.o hello_world.c
gcc hello_world.o -o test test.c
I have no idea what I have done wrong so any help is appreciated.
This is an almost duplicate of Why does the order of '-l' option in gcc matter? - but the behaviour can be replicated without the -l switch by specifying the archive name on command line.
The GNU linker as executed by GCC will, by default, link from left to right, and only use those .o files from the library archive that are needed to satisfy undefined references so far. Since your library precedes the main translation unit on the command line, hello_world is not required at the time the linker is processing it.
The solution is to mention the library after the translation units/object files that depend on it:
gcc -o test test.c libhello.a
I have some problems compiling my test program using PDCurses library. I have compiled PDCurses 3.4 with MinGW compiler 8.2.0. In output I have 2 files panel.a and pdcurses.a. I copied them to C:\MinGW\lib plus the header file curses.h in C:\MinGW\include. But when I try to compile test program I have errors. It seems I have done everything correctly according to instructions and how-to`s.
Some testing C code:
#include <C:\MinGW\include\curses.h>
int main () {
initscr();
mvprintw( 5, 5, "Hello, World!" );
getch();
endwin();
return 0;
}
ERRORS:
c:/Users/username/Dropbox/rakshasa/main.c:4: undefined reference to `initscr'
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe: c:/Users/username/Dropbox/rakshasa/main.c:5: undefined reference to `mvprintw'
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe: c:/Users/username/Dropbox/rakshasa/main.c:6: undefined reference to `stdscr'
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe: c:/Users/username/Dropbox/rakshasa/main.c:6: undefined reference to `wgetch'
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe: c:/Users/username/Dropbox/rakshasa/main.c:7: undefined reference to `endwin'
I have no idea why it is not compiling properly. It looks like compiler cant find libraries in linking stage but I do not know why.
I was try to compile like
gcc -g main.c -o main.exe
Thanks in advance.
Never use absolute paths in #include directives. Instead of #include <C:\MinGW\include\curses.h> you should put #include <curses.h> and compile with -IC:\MinGW\include flag if needed.
Next you need to link with the relevant library using -lpdcurses. If needed you can add the location of the library using -LC:\MinGW\lib.
So if we split compilation and linking steps you need the following commands:
gcc -g main.c -c -o main.o -IC:\MinGW\include
gcc main.o -o main.exe -lpdcurses -LC:\MinGW\lib
though I think you can leave out the -I and -L flags as they point to the location of your compiler's include and lib folders.
Finally: MinGW is a bit outdated and so is GCC 8.2.0. I recommend you switch to MinGW-w64 (which supports both 32-bit and 64-bit Windows). To get a more recent MinGW-w64 GCC build, you can try the standalone builds from https://winlibs.com/.
I just have a system crash and reinstall Ubuntu 11.10, and my code produces this strange error.
I wrote a simple code sample to test where the problem is:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
int main (void) {
int i;
i = shm_open ("/tmp/shared", O_CREAT | O_EXCL, S_IRUSR | S_IWUSR); printf ("shm_open rc = %d\n", i);
shm_unlink ("/tmp/shared");
return (0);
}
and the compile command is
gcc -lrt test.c -o test
The error is:
/tmp/ccxVIUiP.o: In function `main':
test.c:(.text+0x21): undefined reference to `shm_open'
test.c:(.text+0x46): undefined reference to `shm_unlink'
collect2: ld returned 1 exit status
I have already added -lrt lib, why does it still not compile?
Libraries at the end:
gcc test.c -o test -lrt
From GCC Link Options:
-llibrary
-l library
Search the library named library when linking.
(The second alternative with the library as a separate argument
is only for POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option;
the linker searches and processes libraries and object files in the
order they are specified.
Thus, `foo.o -lz bar.o' searches library `z' after file foo.o but
before bar.o. If bar.o refers to functions in `z', those functions
may not be loaded.
Change the compile line from
gcc -lrt test.c -o test
to
gcc test.c -o test -lrt
In Expert C programming Page 108:
<Handy Heuristic>
Where to Put Library Options:Always put the -l library options at the rightmost end of your compilation command line.
But it doesn't tell why, so i guess this is somewhat a rule?:)
For those of you using super-auto-magical CMAKE like me, try to add:
target_link_libraries(your_binary_name PRIVATE librt.so)
to your CMakeLists.txt
Alternatively, replace PRIVATE for PUBLIC as needed..
If you have well established paths to libraries (e.g. all needed libs in /usr/lib), you may be fine with just stating in CMakeLists.txt:
set(CMAKE_CXX_FLAGS "-lrt")
I need to use erl_interface in my C-program. There is Erlang R15B01 on Debian Wheezy.
I just do the following (for example).
// main.c
#include <ei.h>
#include <erl_interface.h>
int main() {
erl_init(NULL,0);
return 0;
}
Then i say:
cc -I/usr/lib/erlang/lib/erl_interface-3.7.7/include -L/usr/lib/erlang/lib/erl_interface-3.7.7/ -lei -lerl_interface -o prog main.c
Directory specified as -L contains libei.a and liberl_interface.a but linker abusing that reference to erl_init is undefined: undefined reference to erl_init
What may be wrong? Sorry for really stupid question.
Newest versions of the GNU toolchain require that the object files and libraries be specified in the same order their symbols depend on each other. So you should generally put the library flags to the end of the invocation, like this:
gcc -o prog main.c -L<libdir> -I<includedir> -lerl_interface -lei