Linker issue while compiling source using hunspell library - c

I'm trying to compile this pure C source code which used hunspell library with gcc (version 4.6.3) on Ubuntu 10.10:
#include <stdlib.h>
#include <stdio.h>
#include <hunspell/hunspell.h>
int main() {
Hunhandle *spellObj = Hunspell_create("/home/artem/en_US.aff", "/home/artem/en_US.dic");
char str[60];
scanf("%s", str);
int result = Hunspell_spell(spellObj, str);
if(result == 0)
printf("Spelling error!\n");
else
printf("Correct Spelling!");
Hunspell_destroy(spellObj);
return 0;
}
With command:
gcc -lhunspell-1.3 example.c
But I've got some linker issues:
/tmp/cce0QZnA.o: In function `main':
example.c:(.text+0x22): undefined reference to `Hunspell_create'
example.c:(.text+0x52): undefined reference to `Hunspell_spell'
example.c:(.text+0x85): undefined reference to `Hunspell_destroy'
collect2: ld returned 1 exit status
Also, I checked /usr/include/hunspell/ folder, file hunspell.h exists and contains all functions from my source.
What I'm doing wrong, and why I can't compile this source?

Try:
$ gcc example.c -lhunspell-1.3
See the documentation for the -l option:
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.
So, you asked GCC to first search the library, then compile your code. You need to do it the other way around, you generally specify the libraries to link against last on the command line.
Also verify the on-disk name of the library file, often there are symlinks that remove the version number from the name, so perhaps your command should just be:
$ gcc example.c -lhunspell
to link against the "current" library version available on your system.

Related

How to link the cs50 C library in gcc on windows

I'm new to ะก programming and have been trying to compile my code using MinGW/GCC, but I try to include cs50 (cs50.c, cs50.h) library, and the compiler can't find it. Help me compile who knows what's going on.
I tried to give such command: gcc -LC:\Users\apple\Desktop -lcs50 mario.c
But the result is this:
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe: cannot find -lcs50
collect2.exe: error: ld returned 1 exit status
Or:
c:/mingw/bin/../lib/gcc/mingw32/8.2.0/../../../../mingw32/bin/ld.exe: C:\Users\apple\AppData\Local\Temp\cc8KpeUr.o:mario.c:(.text+0x33): undefined reference to `GetInt'
collect2.exe: error: ld returned 1 exit status
This is my code:
#include <stdio.h>
#include <cs50.h>
int main()
{
int num = GetInt();
printf("%d\n",num);
}
gcc -LC:\Users\apple\Desktop -lcs50 mario.c
There are two problems here.
Always pass libraries after .c files or they won't actually do anything (unless main is in the library).
You appear to have a library called cs50.a; -lcs50 wants to find a file called libcs50.a or libcs50.so.
The easiest way around this problem is to not bother with -L or -l and just pass your library directly to gcc like this:
gcc mario.c cs50.a
Since cs50.c is a single file, you do not need a library at all. You can compile it as needed to save a few steps, it will consume a couple milliseconds more but most of the time you would not notice.
Just use
gcc mario.c cs50.c
and it will work (provided that both files are in the current folder).
I had the same problem. What i did was that i put the cs50.h and cs50.c files in the same folder or directory as stdio.h ; which you will find in the program files of the compiler you're using. It worked for me. Hope this helps.

C libm.a not needed to be linked when compiling

I was trying to compile a source file that includes <math.h>.
However I succeeded in creating an executable, no error without linking to libm.a.
The command I typed was gcc -Wall filename.c -o executablename
I was told to link to the external libraries (i.e/ libraries other than libc.a)
What's going on?
#include <math.h>
#include <stdio.h>
int main(void)
{
double x = sqrt(2.0);
printf ("The sqrt of 2 is: %f\n", x);
return 0;
}
The math functions you call are implemented by compiler built-in functions. Try the following if you want to see an error message:
gcc -fno-builtin -Wall filename.c -o executablename
For example, on my platform (Ubuntu 14.04.3 LTS), I get this error message:
$ cat x.c
#include <math.h>
#include <stdio.h>
int main(void)
{
double x = sqrt(2.0);
printf ("The sqrt of 2 is: %f\n", x);
return 0;
}
$ gcc -fno-builtin x.c
/tmp/ccpjG2Pb.o: In function `main':
x.c:(.text+0x1c): undefined reference to `sqrt'
collect2: error: ld returned 1 exit status
Some compilers, like the current clang on OS X (which masquerades as gcc) do not need to be told to link your executable with the math library.
The clang on OS X will link your executable with /usr/lib/libSystem.B.dylib (and only this for a simple program). This library in turn uses the library /usr/lib/system/libsystem_m.dylib which is the math library.
The functions in <math.h> (or the preferable <tgmath.h>) are part of the C library just as many other functions. It is platform dependent if all the functions in the C library are actually linked in one single library or separately in multiple chunks.
In ancient times the size of the libraries was a problem for link time, the larger a library was, the longer it took to link executables that had many unresolved symbols. These times are long gone, but the separation on some platforms into libc.a and libm.a prevails.
If your platform doesn't need -lm for linking it should have a dummy (empty) version of libm.a just that there is no error when you have that on your link command line. This is for example the case for the musl C library that is at the base of Alpine Linux.

How do I link to FreeImage?

I am using Kubuntu 14.04, and installed the FreeImage library with
sudo apt-get install libfreeimage-dev
As far as I can tell, it is correctly installed, with FreeImage.h in /usr/include and libfreeimage.a in /usr/lib. However, this trivial C program
#include <FreeImage.h>
int main(int argc, char **argv) {
FreeImage_Initialise(FALSE);
FreeImage_DeInitialise();
return 0;
}
fails to compile. Running
gcc -lfreeimage fitest.c -o fitest
outputs
/tmp/ccFbb0HQ.o: In function `main':
fitest.c:(.text+0x15): undefined reference to `FreeImage_Initialise'
fitest.c:(.text+0x1a): undefined reference to `FreeImage_DeInitialise'
collect2: error: ld returned 1 exit status
What am I doing wrong?
This wouldn't normally be the case with shared libraries but only static ones, but I'm going to give it a shot anyway since it matches your symptoms, and you also mention libfreeimage.a instead of libfreeimage.so, indicating that you're trying to use the static library.
When linking against static libraries, you need to give the library arguments after the explcit source/object arguments to the compiler, because the compiler will only process yet unresolved symbols from the library:
gcc -o fitest fitest.c -lfreeimage
If you give a static library argument before any source/object arguments, then, no symbols will yet be unresolved, nothing will be picked from the library, and the symbols will instead be seen as unresolved at the end.

Undefined reference to functions C

I downloaded a library from here. I added the header file in my program but when I try to access the functions of this header file, I get error:
undefined reference to the function for u_open() and u_accept(). I tried to compile the .c files of this header file but I get this error:
undefined reference to main.
I tried everything in my knowledge to solve this issue, but couldn't solve it. Here is the program.
#include "uici.h"
int main()
{
char client[50];
char buf[1024];
u_port_t portnumber;
portnumber=48625;
int fd = u_open(portnumber);
int communFd = u_accept(fd,client,50);
perror("Opened");
fprintf(stderr,"\nComun fd is %d\n\n\n",communFd);
read(communFd,buf,1024);
write(STDOUT_FILENO,buf,1024);
fprintf(stderr,"\n\nReading complete\n");
return 0;
}
What can I do to solve this problem?
Regards
Your header file uici.h declares the functions you're calling in main() (u_open() and u_accept()), but not their implementations, which are in the source files. When the linker tries to create the entire program, it then complains that the implementations can't be found.
The solution is to link all the files together when creating the actual program binary. When using the g++ frontend, you can do this by specifying all the source files together on the command line. For example:
g++ -o main main.c uici.c
will create the main program called "main", assuming that the implementations you need are in uici.c.
edit: In the case you're linking against a prebuilt library for uici, you'll need to specify to the frontend that the library is needed for linking, e.g. with:
g++ -o main main.c -luici
You need to link the library when using gcc like :
gcc nameofprgram.c -l<library>
Use any of these flags while compiling with gcc
-I <searchpath to include files>
-L <searchpath to the lib file>
-l<thelibname>
Ex:
gcc -o myprogram -lfoo -L/home/me/foo/lib myprogram.c
This will link myprogram with the static library libfoo.a in the folder /home/me/foo/lib

Why does it always say "undefined reference"?

(I'm on Windows.)
I'm testing a DLL I have compiled (libsox) with a C program which looks this way:
#include <stdio.h>
#include "sox.h"
int main(void) {
char const * versionText = sox_version();
printf(versionText);
return 0;
}
The function that is defined in the DLL has the following prototype in sox.h (something of this contains cdecl):
LSX_RETURN_VALID_Z LSX_RETURN_PURE
char const *
LSX_API
sox_version(void);
Here's the problem: When I try to build the file with gcc -lsox -o test.exe test.c I get the following error:
C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\ccSS2h2z.o:test.c:(.text+0xf): undefined reference to `sox_version'
collect2: ld returned 1 exit status
A word to -lsox: I have the library file "libsox.dll.a" in MinGW's lib folder. If I write -lsoxnonsense, then it says there is no library. That means in the shown case it finds the library. So why doesn't it want to create a link.
gcc -lsox -o test.exe test.c
You have to put your source file first:
gcc test.c -lsox -o test.exe
It is because the linker goes through the input files in order, finding undefined references and satisfying references that it saw before. So in your command line, it reads libsox.a (or something like that), finds undefined references (there would be none). Then, it goes to your test.c, finds undefined references in there, but there are no further libraries to satisfy them.
See this answer for more info.

Resources