When using Cygwin and GCC under Win 7 and the quad precision library:
gcc -c lquad.c
... this runs OK, but
gcc lquad.o
... produces the following error:
/tmp/ccLM2lOn.o:lquad.c:(.text+0xdb3): undefined reference to `sqrtq'
collect2: error: ld returned 1 exit status
I have #include quadmath.h in a C source, and the __float128 type works, but not the functions (e.g. sqrtq above). This header file has all the relevant externs, e.g.:
extern __float128 sqrtq (__float128) __quadmath_throw;
I found a dll cygquadmath-0.dll which definitely has these functions in it. It is in 3 places in the Cygwin installation. Additionally, I copied it to Windows\System, but that did not help.
There is a related question here, but nothing helped me there and it is not exactly the same error: Quadruple Precision in C++ (GCC)
You are looking for a compiler solution when what you need is a linker solution:
Your code is compiling as it should, so no change in the code would solve your problem:
/tmp/ccLM2lOn.o:lquad.c:(.text+0xdb3): undefined reference to `sqrtq'
collect2: error: ld returned 1 exit status
The undefined reference to errors indicate a function needed by your object is in another library.
As suggested by #Marc Glisse, try adding -lquadmath to your linker line.
Related
I'm trying to compile and link a custom made c code to risc v project but I'm getting these error in the making:
I'm new to this field so please excuse any mistakes.
/local/home/opt/riscv/lib/gcc/riscv32-unknown-elf/9.2.0/../../../../riscv32-unknown-elf/bin/ld:
/local/home/opt/riscv/lib/gcc/riscv32-unknown-elf/9.2.0/../../../../riscv32-unknown-elf/lib/crt0.o:
in function `_start':
(.text+0x0): undefined reference to `__global_pointer$'
/local/home/s2500108/riscv/lib/gcc/riscv32-unknown-elf/9.2.0/../../../../riscv32-unknown-elf/bin/ld: (.text+0x8): undefined reference to `_edata'
/local/home/s2500108/riscv/lib/gcc/riscv32-unknown-elf/9.2.0/../../../../riscv32-unknown-elf/bin/ld: (.text+0x10): undefined reference to `_end'
collect2: error: ld returned 1 exit status
I also wanted to ask this:
After executing ./configure --prefix=/local/home/s2500108/riscv --with-abi=ilp32 --with-arch=rv32i
+ make
and trying to compile a multiplication instruction in c code examle a=21, b=10; a * b the compiler does not output any error and produces elf files normally. Why is this happening? I want to make sure that no multiplication will take place.
I have a very old C program and want to compile to Windows. So I try doing this:
gcc -DNO_GLIBC=1 sakide.c -o sakide.exe
and this returns:
\AppData\Local\Temp\ccx7khiy.o:sakide.c:(.text+0xa4): undefined reference to `ekiGetLibVersion'
\AppData\Local\Temp\ccx7khiy.o:sakide.c:(.text+0x6b6): undefined reference to `ekiGetLibVersion'
\AppData\Local\Temp\ccx7khiy.o:sakide.c:(.text+0x8ff): undefined reference to `ekiEncodeUrl'
\AppData\Local\Temp\ccx7khiy.o:sakide.c:(.text+0x954): undefined reference to `ekiDecodeUrl'
\AppData\Local\Temp\ccx7khiy.o:sakide.c:(.text+0x993): undefined reference to `ekiDecodeUrl'
\AppData\Local\Temp\ccx7khiy.o:sakide.c:(.text+0xa62): undefined reference to `ekiGetKeyInfo'
collect2.exe: error: ld returned 1 exit status
This ekiGetLibVersion is in a .h file:
INT EKIAPI ekiGetLibVersion(char *outBuffer, LPINT outBufferSize);
and I also have a .dll name of it.
Ive never compiled anything with C though
On windows you cannot link against directly with the .dll, you have to link the import library, name .lib. For more information, refer:
On dynamic linking:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682592(v=vs.85).aspx
On implicit linking:
https://msdn.microsoft.com/en-us/library/d14wsce5.aspx
You are getting linker errors.
You need to link the library (or object file) where those functions are defined.
Undefined reference usually means the compiler has not seen a proper declaration for this variable. Did you include the header file (which defines this variable) in your C program ?
#include "header_file.h"
I am trying to use the function exp1 and log101 which take long doubles as input and output long doubles in turn. However, when I try to compile the file I get the following error message:
/tmp/ccIvBVbG.o: In function `main':
derivative.c:(.text+0x250): undefined reference to `log101'
collect2: ld returned 1 exit status
I have included math.h library and also provided the -lm option. What is the remedy to this issue? Any help and comments are appreciated.
Thanks
P.S. Compiler is GCC on 32-bit Ubuntu 12.04 LTS
The names of the functions you are trying to use are exp10l and log10l. The last character in the name is a lowercase L, not another 1.
I want to replace pthread_mutex_lock by pthread_mutex_trylock in a function and when I do so, I get the "undefined reference" error message (See below). If I replace the lines 411-13 by pthread_mutex_lock(&cmd_queue_lock), I don't get the linker error.
They are both from the same library which I already include. Why does one generate the linker error and the other doesn't? More importantly, how can I fix it? I tried adding "extern int pthread_mutex_trylock" and changing the order of the .o files in Makefile but both don't work.
$ nl clientmain.c
12 #include <stdio.h>
...
21 #include <pthread.h>
411 if (pthread_mutex_trylock(&cmd_queue_lock) == EBUSY) {
412 continue;
413 }
$ make
clientmain.o: In function `createHC':
clientmain.c:411: undefined reference to `pthread_mutex_trylock'
collect2: ld returned 1 exit status
make: *** [clientmain] Error 1
Admittedly I can't find any reference to a manual page telling this, but adding -lpthread to your final linking phase will probably do the job. I found it by looking for the symbol pthread_mutex_trylock in all /usr/lib/lib*.a files and /usr/lib/libpthread.a was the only one defining the symbol. Reverse engineering.
The manual page of gcc does say that you can/should use the -pthread option to gcc to include POSIX thread support, so that is probably the royal route. This option worked on my system too. Interestingly the regular /usr/lib/libc.a does offer the pthread_mutex_lock but not the pthread_mutex_trylock so that caused your confusion. Note that the manual page of gcc is also saying that this option has effect on preprocessing, so it may be more and better than just linking against /usr/lib/libpthread.a.
When installing the Haskell GD package through cabal, on Windows (using MinGW), I get the following warnings:
Warning: resolving _gdImagePtrDestroyIfNotNull by linking to _gdImagePtrDestroyIfNotNull#4
Warning: resolving _gdImageCopyRotated90 by linking to _gdImageCopyRotated#36
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Note that these are precisely the functions defined in gd-extras.
Then, when actually compiling a Haskell program which uses gd, I get the following errors:
Linking Main.exe ...
[...]\cabal\gd-3000.7.3\ghc-7.4.1/libHSgd-3000.7.3.a(Internal.o):fake:(.text+0x2211):undefined reference to 'gdImageCopyRotated90'
[...]\cabal\gd-3000.7.3\ghc-7.4.1/libHSgd-3000.7.3.a(Internal.o):fake:(.text+0x500a):undefined reference to 'gdImagePtrDestroyIfNotNull'
[...]
collect2: ld returned 1 exit status
I'm unable to figure out how to fix this — it's already taken me ages to get to this point, as I've had many more issues trying to get it working, but this seems like the final hurdle. I have tried enabling/disabling stdcall fixup, and also changing in which file these functions are defined (as gd-extras seemed to be a potential issue), but that hasn't adressed the issues.
Thanks for any help.
You need to pass explicit linker flags to ghc, pointing to the library. The Haskell GD library is automatically linked, but the dll will not be linked as well unless you tell ghc about it. The stdcall-fixup errors are a red herring here.