Single file program with PDCurses fails to compile with "undefined reference to" - c

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/.

Related

gcc undefined reference to portaudio functions

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.

How to use dialog.h in a c program

I am trying to use dialog.hin my C program. For this I looked up the manual (man 3 dialog) and used the example code, which they have provided. This is how my C program look like (it is called main.c):
#include <dialog.h>
int main(void)
{
int status;
init_dialog(stdin, stdout);
status = dialog_yesno(
"Hello, in dialog-format",
"Hello World!",
0, 0);
end_dialog();
return status;
}
After research I figured out, that the dialog program is based on ncurses. So I have installed both libraries, which contains the required header files.
I am working on Debian so:
apt install dialog libncurses5-dev libncursesw5-dev
In the next step I have called the compiler, and I have also linked the libraries: gcc main.c -ldialog -lncurses
But compiling did not succeed.
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(util.o): In function `dlg_auto_size':
(.text+0x1a06): undefined reference to `sqrt'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(trace.o): In function `dlg_trace_win':
(.text+0x29c): undefined reference to `win_wch'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(trace.o): In function `dlg_trace_win':
(.text+0x2ab): undefined reference to `wunctrl'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(arrows.o): In function `dlg_draw_arrows2':
(.text+0x2c4): undefined reference to `_nc_wacs'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(arrows.o): In function `dlg_draw_arrows2':
(.text+0x2d6): undefined reference to `wadd_wch'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(arrows.o): In function `dlg_draw_arrows2':
(.text+0x43c): undefined reference to `_nc_wacs'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(arrows.o): In function `dlg_draw_arrows2':
(.text+0x44e): undefined reference to `wadd_wch'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(arrows.o): In function `dlg_draw_scrollbar':
(.text+0x878): undefined reference to `_nc_wacs'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(arrows.o): In function `dlg_draw_scrollbar':
(.text+0x88f): undefined reference to `wvline_set'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(inputstr.o): In function `dlg_index_columns':
(.text+0x932): undefined reference to `setcchar'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(inputstr.o): In function `dlg_index_columns':
(.text+0x93c): undefined reference to `wunctrl'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libdialog.a(ui_getc.o): In function `dlg_getc':
(.text+0x603): undefined reference to `wget_wch'
collect2: error: ld returned 1 exit status
After research I found out that the missing references to some functions like win_wch, wunctrl, etc. are all defined in curses.h.
Regarding to this post (What's the difference between -lcurses and -lncurses when compiling C using ncurses lib?) ncurses and curses are the same due curses is linked to ncurses.
But anyway, I have tried to compile with the curses library too: gcc main.c -lcurses -lncurses -ldialog. But it did not work either.
What am I missing? Why did compiling fail?
I did some testing on a Debian-based system (a Beaglebone), and this was not an obvious fix. Turns out there are multiple versions of the ncurses library, and the dialog library was built with one of them, just not the one you were using.
The way you're supposed to figure this out is with the dialog-config command, which has options to show which CFLAGS or libraries you need on the compile line (or in the makefile), but I didn't find it on my system, so I looked at /usr/include/dlg_config.h for some clues:
...
#define DLG_HAVE_LIBINTL_H 1
#define DLG_HAVE_LIBNCURSESW 1 <---
#define DLG_HAVE_LIMITS_H 1
Hmmm, this suggests it needs -lncursesw instead of -lncurses, so we see this compile:
$ gcc dlg.c -ldialog -lncursesw
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/libdialog.a(util.o): in function `dlg_auto_size':
(.text+0x13d2): undefined reference to `sqrt'
Ok, so a lot closer: sqrt() is in the math library, so adding -lm gets it over the goal line:
$ gcc dlg.c -ldialog -lncursesw -lm
It seems that ncursesw is a wide-character version that works with an international character set, which was new to me.
EDIT: Elaborating on the "dialog-config" stuff: The way you're supposed to do this is documented in the dialog(3) manual page:
gcc $(dialog-config --cflags) file ... $(dialog-config --libs)
The idea is that a package can publish what it needs to build in a command, so in this case I imagine that dialog-config --cflags might not output anything, but dialog-config --libs would output -ldialog -lncursesw -lm, so you could embed this in your makefile and have it do the right thing.
This paradigm is common, and on my system I see (for example) /usr/bin/python-config that shows how it was built on this machine:
$ python-config --cflags
-I/usr/include/python2.7 -I/usr/include/arm-linux-gnueabihf/python2.7
-fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
-fdebug-prefix-map=/build/python2.7-RT6aMn/python2.7-2.7.16=.
-fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG
-g -fwrapv -O2 -Wall -Wstrict-prototypes
$ python-config --libs
-lpython2.7 -lpthread -ldl -lutil -lm
If you were trying to build some kind of Python plugin, guessing the above parameters would be a real challenge.

libfixmath undefined reference

I´m trying to produce a little example code for the library libfixmath and I get the error "undefined reference to `fix16_mul' "
The code is:
#include <stdio.h>
#include "libfixmath/fixmath.h"
int main(){
fix16_t res = fix16_mul(fix16_from_int(1), fix16_from_int(2));
return 0;
}
The library is at the specified path and I compile just with the command
gcc -o testfix testfix.c
The documentation says
To use the fixmath library, include the header <fixmath/fixmath.h>, and link the application with -lfixmath, or use pkg-config to determine the compiler and linker flags.
So change
gcc -o testfix testfix.c
to
gcc -o testfix testfix.c -lfixmath
and it should work.

erl_interface linker error

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

GCC: How can I make this compiling and linking work?

I want to use from the file tester-1.c functions that I defined in libdrm.h and gave implementation in libdrm.c. The three files are on the same folder and use pthread functions.
Their include files are:
libdrm.h
#ifndef __LIBDRM_H__
#define __LIBDRM_H__
#include <pthread.h>
#endif
libdrm.c <- has no main()
#include <stdio.h>
#include <pthread.h>
#include "libdrm.h"
tester-1.c <- has teh main()
#include <stdio.h>
#include <pthread.h>
#include "libdrm.h"
The compiler error for libdrm.c says:
gcc libdrm.c -o libdrm -l pthread
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
And the compiler errors for tester-1.c say:
gcc tester-1.c -o tester1 -l pthread
/tmp/ccMD91zU.o: In function `thread_1':
tester-1.c:(.text+0x12): undefined reference to `drm_lock'
tester-1.c:(.text+0x2b): undefined reference to `drm_lock'
tester-1.c:(.text+0x35): undefined reference to `drm_unlock'
tester-1.c:(.text+0x3f): undefined reference to `drm_unlock'
/tmp/ccMD91zU.o: In function `thread_2':
tester-1.c:(.text+0x57): undefined reference to `drm_lock'
tester-1.c:(.text+0x70): undefined reference to `drm_lock'
tester-1.c:(.text+0x7a): undefined reference to `drm_unlock'
tester-1.c:(.text+0x84): undefined reference to `drm_unlock'
/tmp/ccMD91zU.o: In function `main':
tester-1.c:(.text+0x98): undefined reference to `drm_setmode'
tester-1.c:(.text+0xa2): undefined reference to `drm_init'
tester-1.c:(.text+0xac): undefined reference to `drm_init'
tester-1.c:(.text+0x10e): undefined reference to `drm_destroy'
tester-1.c:(.text+0x118): undefined reference to `drm_destroy'
All these functions are defined in libdrm.c
What gcc commands should I use to make these files compile and link?
To compile your .c sources to object files, use GCC's -c option. Then you can link the object files to an executable, against the required library:
gcc libdrm.c -c
gcc tester-1.c -c
gcc tester-1.o libdrm.o -o tester1 -lpthread
Doing compiling and linking in one go, as many others have suggested, works fine too. However, it's good to understand that the build process involves both of these stages.
Your build failed, because your translation modules (=source files) required symbols from each other.
libdrm.c alone couldn't produce an executable, because it does not have a main() function.
tester-1.c's linking failed, because the linker wasn't informed about the required symbols defined in libdrm.c.
With -c option, GCC compiles and assembles the source, but skips linking, leaving you with .o files, which can be linked into an executable or packaged into a library.
gcc tester-1.c libdrm.c -o tester1 -l pthread
You need to compile all the source files in one go rather than doing them individually. Either that or compile libdrm.c as a library and then link it with tester1.c when you compile that.
gcc test-1.c libdrm.c -o libdrm -l pthread

Resources