I'm getting some undefined references when building my project. Here's the build log:
**** Build of configuration Debug for project test ****
**** Internal Builder is used for build ****
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o src\main.o ..\src\main.cpp
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o src\test.o ..\src\test.cpp
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o src\window.o ..\src\window.cpp
..\src\window.cpp: In member function 'void Window::StartRenderContext()':
..\src\window.cpp:150:24: warning: NULL used in arithmetic
..\src\window.cpp:161:28: warning: NULL used in arithmetic
..\src\window.cpp:174:24: warning: NULL used in arithmetic
g++ -mwindows -l glew32 -l glew32s -l glu32 -l opengl32 -o test.exe src\window.o src\test.o src\main.o
src\window.o: In function `ZN6Window18StartRenderContextEv':
C:\eclipse\workspace\test\Debug/../src/window.cpp:101: undefined reference to `wglCreateContext#4'
C:\eclipse\workspace\test\Debug/../src/window.cpp:102: undefined reference to `wglMakeCurrent#8'
C:\eclipse\workspace\test\Debug/../src/window.cpp:115: undefined reference to `glewInit'
C:\eclipse\workspace\test\Debug/../src/window.cpp:125: undefined reference to `wglMakeCurrent#8'
C:\eclipse\workspace\test\Debug/../src/window.cpp:126: undefined reference to `wglDeleteContext#4'
C:\eclipse\workspace\test\Debug/../src/window.cpp:148: undefined reference to `__wglewChoosePixelFormatARB'
C:\eclipse\workspace\test\Debug/../src/window.cpp:159: undefined reference to `__wglewChoosePixelFormatARB'
C:\eclipse\workspace\test\Debug/../src/window.cpp:185: undefined reference to `__wglewCreateContextAttribsARB'
C:\eclipse\workspace\test\Debug/../src/window.cpp:194: undefined reference to `__wglewCreateContextAttribsARB'
C:\eclipse\workspace\test\Debug/../src/window.cpp:204: undefined reference to `__wglewCreateContextAttribsARB'
C:\eclipse\workspace\test\Debug/../src/window.cpp:214: undefined reference to `__wglewCreateContextAttribsARB'
C:\eclipse\workspace\test\Debug/../src/window.cpp:227: undefined reference to `wglMakeCurrent#8'
collect2: ld returned 1 exit status
Build error occurred, build is stopped
Time consumed: 8128 ms.
Here's my link command:
g++ -mwindows -l glew32 -l glew32s -l glu32 -l opengl32 -o test.exe src\window.o src\test.o src\main.o
Is this correct? I'm using the 64-bit binaries of glew (I think the 32s don't mean anything). Were they only meant to be used with visual studio?
Here's the includes in my code:
#include "Windows.h"
#include "GL/glew.h"
#include "GL/wglew.h"
#include "GL/gl.h"
#include "GL/glu.h"
#include "test.h"
I am using Eclipse Indigo CDT, MinGW, Win32, OpenGL, and glew.
I solved "glew undefined reference" problems.
My development environment is eclipse CDT with MinGW on Windows 7 (x64).
The solution is the following 3 steps:
Add source code: #define GLEW_STATIC
Add linker flag: -lglew32s -lopengl32 -lfreeglut
Add compiling flag: gcc -DGLEW_STATIC
If needed, you have to add -lglu32 -glut32 etc.
Related
I've started writing my very own kernel and am developing on Windows 10.
I am using the following tools:
gcc 8.1.0 elf x86_64 for compiling my C code, and for linking.
I am using this Windows package.
nasm 2.14.02 for compiling my assembly code.
I am using the following command to build my freestanding kernel code:
gcc -c -m64 common/src/kernel.c -o common/build/kernel.o -std=gnu99 -ffreestanding -O2 -Wall -Wextra`
I am using the following command for compiling the root assembly code:
nasm -f elf64 targets/x86_64/src/main.asm -o targets/x86_64/build/main.o
Finally I link the object files together:
gcc -o dist/x86_64/main.bin -ffreestanding -O2 targets/x86_64/build/main.o common/build/kernel.o -lgcc
I haven't a clue why, but the following error is stopping the linking process from working:
... undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status
This doesn't make sense to me because my compilation and linking is in freestanding mode and I am not attempting to use any windows APIs.
How do I fix this?
If it matters, here is my very simple code:
main.asm:
EXTERN kernel_main
call kernel_main
jmp $
; padding and magic number
times 510-($-$$) db 0
dw 0xaa55
kernel.c:
void kernel_main()
{
// empty
}
Edit: It looks like I might need the x86_64-elf-gcc compiler
Edit 2: I tried the x86_64-w64-mingw32-gcc compiler, same error occurs
I was missing the -nostdlib flag on the linker. This seems to have solved the problem.
I am running the following version of clang on a Mac OS X host:
$ clang -v
Apple LLVM version 8.1.0 (clang-802.0.42)
I have some code that uses the aligned_alloc() C11 function to allocate an aligned chunk of memory.
I am compiling my binary with the -std=c11 flag:
...
clang -g -Wall -Wextra -mavx -std=c11 -D__USE_POSIX -D__STDC_CONSTANT_MACROS -D__STDINT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -O2 -c my_binary.c -o my_binary.o; \
clang -g -Wall -Wextra -mavx -std=c11 -D__USE_POSIX -D__STDC_CONSTANT_MACROS -D__STDINT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -O2 my_binary.o -o my_binary -lm; \
...
I am including stdlib.h and adding POSIX flags. From my_binary.h:
...
#ifndef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE 200809L
#endif /* getline() support */
#ifndef _XOPEN_SOURCE
#define _XOPEN_SOURCE 600
#endif /* aligned_alloc() support */
#include <stdlib.h>
...
I get the following compilation warning:
my_binary.c:245:15: warning: implicit declaration of function 'aligned_alloc' is invalid in C99 [-Wimplicit-function-declaration]
s->data = aligned_alloc(32, s->n * sizeof(*s->data));
Which follows with this error:
Undefined symbols for architecture x86_64:
"_aligned_alloc", referenced from:
_bs_initialize_signal_avx in my_binary.o
_bs_copy_signal_avx in my_binary.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [build] Error 1
What am I doing incorrectly with clang, such that compilation ignores the std C11 flag?
I am able to compile without errors on a CentOS 7 (Linux) host with gcc 5.3.0 and glibc 2.22.
I'm running into an issue after upgrading gcc from 4.1.1 to 4.7.2. The problem is that the ld --as-needed flag is not pruning libraries that are not required if enough libraries with inter dependencies are listed.
For example, if I build a simple program that doesn't need any special libraries, but includes them on the build line, as such
gcc -m32 test.c -Wl,--as-needed -L/usr/local/lib -lrt -lprojcommon -lproj -lrte -o test
then it builds fine and the --as-needed flag does it's job pruning out all of the listed libs that are not needed.
ldd test
linux-gate.so.1 => (0x00bfc000)
libc.so.6 => /lib/libc.so.6 (0x001ac000)
/lib/ld-linux.so.2 (0x0018a000
However, if I add one more library (in this case crypto), then the build fails with undefined reference errors.
gcc -m32 test.c -Wl,--as-needed -L/usr/local/lib -lcrypto -lrt -lprojcommon -lproj -lrte -o test
/usr/local/lib/librte.so: error: undefined reference to 'tla_decap_data'
/usr/local/lib/librte.so: error: undefined reference to 'do_db'
collect2: error: ld returned 1 exit status
This exact same build worked with 4.1.1, but started failing with 4.7.2.
This is part of a general build infra and libraries included on the build line are generic and expected to be pruned via --as-needed. I could fix this with --allow-shlib-undefined, but I'd prefer to find real unresolved symbols at build time. If I do set --allow-shlib-undefined, then I end up with the same set of required libs as the build that worked.
Any insight would be appreciated.
I am trying compile code that uses snprintf in version 4.8.2 of g++ with -std=c++11 without success.
Why doesn't g++ recognize snprintf? Can I overcome this while still using snprintf and c++11?
I got the following:
make all Building file: ../src/cppHWtest.cpp Invoking: Cygwin C++
Compiler g++ -std=c++11 -D"hash_map=unordered_map" -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MF"src/cppHWtest.d" -MT"src/cppHWtest.d" -o "src/cppHWtest.o" "../src/cppHWtest.cpp" cygwin warning: MS-DOS style path detected: C:\Users\poudyal\workspace\cppHWtest\Debug
Preferred POSIX equivalent is:
/cygdrive/c/Users/poudyal/workspace/cppHWtest/Debug CYGWIN
environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames ../src/cppHWtest.cpp: In function 'int main()':
../src/cppHWtest.cpp:20:35: error: 'snprintf' was not declared in this
scope snprintf(buff, 10, "%s", "Hell O");
^ make: *** [src/cppHWtest.o] Error 1 src/subdir.mk:18: recipe for target 'src/cppHWtest.o' failed
**** Build Finished ****
Probably less intrusive solution than switching the mode to -std=gnu++11 is -U__STRICT_ANSI__. This will enable #if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) at stdio.h:234 (GCC 4.8.3).
I am trying to use libjpeg in my application. Making the project yields a libjpeg.a in .libs folder. What I would like to do is to use this file in the linkage stage. I have tried the following: I copied the libjpeg.a into the folder where my C code resides. Trying to link with
gcc libjpeg.a mycode.c -o executable_name
fails. If I do gcc -ljpeg mycode.c, the compilation is successful when I change my header to point to instead of "libjpeg.h", but this obviously links to the system-wide dynamic version of the library.
Trying to link with relative or absolute path also fails:
gcc ./libjpeg.a mycode.c -o executable_name
I have tried the static option as well:
gcc -static libjpeg.a mycode.c -o executable_name
The linker error is the following:
Linking...
gcc -std=c99 -Wall -Wextra -g -pedantic ./libjpeg.a ./libjpeg.a -lm obj/read_jpeg.o obj/utils.o -o test_jpeg
obj/read_jpeg.o: In function `read_JPEG_file':
/home/ustun/Downloads/jpeg_test/read_jpeg.c:37: undefined reference to `jpeg_std_error'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:45: undefined reference to `jpeg_CreateDecompress'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:46: undefined reference to `jpeg_stdio_src'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:47: undefined reference to `jpeg_read_header'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:48: undefined reference to `jpeg_start_decompress'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:62: undefined reference to `jpeg_read_scanlines'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:74: undefined reference to `jpeg_finish_decompress'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:75: undefined reference to `jpeg_destroy_decompress'
obj/read_jpeg.o: In function `read_JPEG_file_props':
/home/ustun/Downloads/jpeg_test/read_jpeg.c:93: undefined reference to `jpeg_std_error'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:100: undefined reference to `jpeg_CreateDecompress'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:101: undefined reference to `jpeg_stdio_src'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:102: undefined reference to `jpeg_read_header'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:103: undefined reference to `jpeg_start_decompress'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:113: undefined reference to `jpeg_read_scanlines'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:116: undefined reference to `jpeg_finish_decompress'
/home/ustun/Downloads/jpeg_test/read_jpeg.c:117: undefined reference to `jpeg_destroy_decompress'
collect2: ld returned 1 exit status
make: *** [test_jpeg] Error 1
You can download a simple project with a Makefile here.
You'd have to give the full path to libjpeg.a, If you have libjpeg.a in a .libs folder relative to where you compile:
gcc mycode.c -o executable_name .libs/libjpeg.a
If your special libjpeg.a is elsewhere, give a full path to it.
If this fails, you have to tell us what happens. (the details are important, so please copy paste the exact errors and the exact command line that is run).
You need to use -static:
gcc -static -o exec_name mycode.c -ljpeg
No need to copy the archive (.a). You could have found out by reading man ld.
This may help you if you have the same problem as mine. In my system, I have
libjpeg.so.62 -> libjpeg.so.62.0.0
libjpeg.so.62.0.0
After I added symbolic link:
sudo ln -s libjpeg.so.62 libjpeg.so
My problem got solved.