I can't use C++ syntax like cout, so I've tried using <conio.h> but it still says
undefined reference to '_gotoxy'
What's the problem? Everyone says that conio.h its not in K&R either because it isn't a standard library. Anyone got an idea?
I am using MinGW and command prompt.
When linking you need to add the ncurses library:
$ gcc my-source.c -o my-program -lncurses
That last flag to the command line above (-lncurses) is what tells the compiler to link (-l) with the ncurses library.
Related
I'm trying to use the Mingw-w64 toolchain provided by LH_Mouse, version 10.2.1.
When compiling this small program:
#include <windows.h>
#include <stdio.h>
int wmain()
{
wprintf(L"Hello world!\n");
ExitProcess(0);
}
with the following command:
gcc.exe test.c -o test64.exe -municode -s -Os -Wall -nostdlib -lmsvcrt -lkernel32 -e wmain
I get an error: undefined reference to `__mingw_vfwprintf'
Z:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: R:\Temp\ccDSsj2M.o:test.c:(.text+0x3d): undefined reference to `__mingw_vfwprintf'
collect2.exe: error: ld returned 1 exit status
I previously used Mingw-w64 7.3.0 provided on SourceForge and everything worked fine.
Of course I can use the stdlib (and in this case there is no error) but this increases the size of the executable.
I have read that some changes have been done recently to support UCRT. Is it related?
Is there a way to use msvcrt like before?
Edit: using -lmingwex does not really help. If located after -lmsvcrt, it produces a huge amount of varied "undefined reference" errors. If located before, we got several "undefined reference" to ___chkstk_ms, and one to _pei386_runtime_relocator.
The first ones can be removed by adding -lgcc after -lmingwex. For the last "undefined reference", I have found nothing. Adding -lmingw32 does not help, no matter its location.
So for now, the only possibilities I see are to either modify stdio.h, or create my own declarations.
Well, I use mingw since many years and its not the biggest issue I encountered. But I am a bit disappointed that it affects such basic functions.
You are trying to compile your application with -nostdlib option which means that standard C functions (like printf, scanf, wprintf, ...) are not available for your application. Therefore you should not include standard C header files (like stdio.h, stdlib.h, ...) and also you should not use wprintf in your application.
If you really want to standard C function with -nostdlib option then you have to write your own C header files and also your own implementation of standard C functions (like wprintf).
What you did was to include MinGW's stdio.h header file which calls lot of standard C functions and also internal MinGW functions and then told gcc (via -nostdlib to not link these standard functions and neither internal MinGW functions. Which obviously resulted in lot of linker errors.
Then you have tried to manually link msvcrt.dll library but it failed too as this Windows library does not contain internal MinGW functions used in MinGW's stdio.h header file.
If you really want not use standard C functions from gcc/MinGW (via -nostdlib option) but rather directly via Windows msvcrt.dll library then you have to use also Windows stdio.h header file and not MinGW one. But beware that Windows header file stdio.h is not supported for gcc compiler and it also does not have to work.
So you should first answer questions, why you are trying to use standard C functions (like wprintf) without standard C library with gcc compiler? This sounds really strange and such thing is common only in freestanding environment or for bare-metal applications (like firmware, bootloader, kernel, ...). Are you workarounding some other bug which you have not mentioned?
And to answer your question, why in previous version it (probably) worked fine. Older version of gcc compiled C code according to C89 standard (with GCC extensions). New version of gcc started to compile C code according to C11 standard. Windows library msvcrt.dll provides only subset of standard C functions and only for C89 standard. For this reason MinGW provides its own implementation (or fixes) for some standard C functions to be compliant with C99 and C11 standards. As older gcc compiled your application as C89 code and manually linked msvcrt.dll library provided somehow compatible implementation for printf and wprintf, it resulted in final exe file without errors. Now with new gcc you are compiling your application as C11 code and you are trying to call C11 wprintf function but this function in msvcrt.dll is not compatible with C11 and therefore you get lot of errors.
Windows provides C11 standard functions in UCRT libraries. msvcrt.dll provides only subset of C89.
So you really should not compile your application with -nostdlib if your intention is to produce executable application and use standard C functions.
You can instruct new gcc to compile your C application as C89 with option -std=c89. This should instruct new gcc to behave like old gcc.
When I tried to include <math.h> I found that I need to link math library by using command gcc -lm
But I am searching for another way to link the math library 'in code', that does not require the user to compile using any options..
Can gcc -lm be done in C code using #pragma or something?
EDIT: I have changed -ml to -lm
The usual way to simplify complication for the user (or indeed for the developer) is to write a makefile.
First, it's gcc -lm and no there is no #pragma meant to give linking directives
No, you need to tell the linker to link the library in order to link the library.
The linker doesn't know about the code, only the compiled object files. It won't see a language specific pragma.
You don't say which UNIX shell you are using, but if this is just for conveniance, simply write a shell function:
gcm() {
gcc -lm $*
}
Put that in your shell's startup file and you can compile and link with the maths library with:
gcm mycode.c
Using -lm is the only option. Additionally, using #pragma for that is microsoft-specific and rather dirty. Imagine there is a new super-efficient math library which requires -lsupermath instead of -lm - then you'd have to modify your code instead of modifying a makefile or a make config file.
No, gcc has no pragmas for linking to libraries. You have to link to the math library with command line options (it's -lm not -ml )
I was writing some codes in linux using c. When tried to compiled, I got this response:
/tmp/ccW8mQDx.o: In function `main':
server.c:(.text+0x3e): undefined reference to `__gmpz_set_str'
server.c:(.text+0x5a): undefined reference to `__gmpz_set_str'
In fact, all the functions of gmp that I used couldn't be found.
Seems there are some problem with the gmp.
Could anyone please tell me how to solve it? Thanks in advance!
The undefined reference errors appear when you forgot to link your application with the library, GMP in this case. Read in the documentation of GMP the name of the library to link and use the -l compiler switch to link it.
Have you tried -lgmp ?
If that doesn't work you can look for the libgmp.a library:
cd /usr
find . -name libgmp.a -print
Add -l option ,when you compile the code. It will add the library files.
Trying to get getch() working to capture key press.
#include <curses.h>
...
...
WINDOW *w;
char f;
w = initscr();
timeout(3000);
f = getch();
endwin();
is giving me following error:-
undefined reference to `wgetch'
undefined reference to `stdscr'
That's a linking error. Are you linking to the curses library correctly?
There are two steps involved in using a library in C.
You #include the relevant header files from your source files. This is so your code knows what signatures of the library functions are. So you're doing this correctly.
When compiling your code, you need to tell the linker to link to the relevant libraries, so it can find the definition of those functions. This is what you're not doing. Assuming you're using gcc then adding -lncurses to the compile line should do it. Here's an explanation of linking.
The above answers are correct but the format is:
gcc -Wall program.c -o name_of_binary -lncurses
When I did:
gcc -Wall -lncurses program.c...
It did not work so apparently it should be tacked on the end.
I'm trying to start developing a program using ncurses on Linux. I can't even get the Hello World example to compile. Here's the code:
#include <curses.h>
int main()
{
initscr();
printw("Hello, world.");
refresh();
getch();
endwin();
return 0;
}
When I attempt to compile, I get:
hello.c:(.text+0x12): undefined reference to `initscr'
For every one of those called functions.
I installed ncurses via apt-get, and also by downloading the sources and compiling, installing, etc.
I have tried #include both curses.h and ncurses.h.
What is going on?
Have you used the -lcurses option when linking?
Including the header files let the code compile (because the compiler knows what the function call looks like from the .h file), but the linker needs the library file to find the actual code to link into your program.
As Greg Hewgill said, you need to pass in -lcurses or -lncurses to link to the curses library.
gcc -o hello hello.c -lncurses
You also probably mean to use initscr() and getch(). Once I make those substitutions, the above compiles for me.
I was having a similar issue and found a solution which helped me, but was slightly different from the other answers posted here. I was trying to use the panels library with curses and my compile command was:
$ gcc -o hello hello.c -lncurses -lpanel
when I read the other answers, I was baffled because I was including the -lncurses flag, but it still was not compiling, and with similar errors to what you were getting:
$ gcc -o hello hello.c -lncurses -lpanel
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libpanel.a(p_new.o): In function `new_panel':
p_new.c:(.text+0x18): undefined reference to `_nc_panelhook'
I finally found my answer in the tldp:
"To use panels library functions, you have to include panel.h and to link the program with panels library the flag -lpanel should be added along with -lncurses in that order."
So, it appears that order is important when using the compile flags! I tried switching the order:
gcc -o hello hello.c -lpanel -lncurses
This allowed it to compile successfully. I know you already have your answer, so I hope this helps someone.
For anyone having similar problems: -lx arguments, where x is your library, should always follow the source and object files.