C:/UnixUtils/usr/local/bin/rm -f *.o
C:/minGW/bin/g++.exe -I"C:/minGW/include" -I"C:\minGW\include\c++\3.2.3" -I"C:\minGW\include\c++\3.2.3\bits" -I"C:\minGW\include\c++\3.2.3\backward" -I"C:\minGW\include\c++\3.2.3\ext" -I"C:\minGW\include\c++\3.2.3\mingw32\bits" -c main.cpp
C:/minGW/bin/g++.exe -I"C:/minGW/include" -I"C:\minGW\include\c++\3.2.3" -I"C:\minGW\include\c++\3.2.3\bits" -I"C:\minGW\include\c++\3.2.3\backward" -I"C:\minGW\include\c++\3.2.3\ext" -I"C:\minGW\include\c++\3.2.3\mingw32\bits" -c scene.cpp
C:/minGW/bin/g++.exe -I"C:/minGW/include" -I"C:\minGW\include\c++\3.2.3" -I"C:\minGW\include\c++\3.2.3\bits" -I"C:\minGW\include\c++\3.2.3\backward" -I"C:\minGW\include\c++\3.2.3\ext" -I"C:\minGW\include\c++\3.2.3\mingw32\bits" -c mathvector.cpp
C:/minGW/bin/g++.exe -L"C:\minGW\lib" -mwindows -lopengl32 -lglaux -lglut32 -lglu32 -lSDLmain -lSDL SDL.dll main.o scene.o mathvector.o -o assign.exe
main.o(.text+0x6d5):main.cpp: undefined reference to `glClearColor@16'
main.o(.text+0xa13):main.cpp: undefined reference to `glViewport@16'
main.o(.text+0xa20):main.cpp: undefined reference to `glMatrixMode@4'
main.o(.text+0xa28):main.cpp: undefined reference to `glLoadIdentity@0'
main.o(.text+0xa4f):main.cpp: undefined reference to `gluPerspective@32'
main.o(.text+0xa5c):main.cpp: undefined reference to `glMatrixMode@4'
main.o(.text+0xa64):main.cpp: undefined reference to `glLoadIdentity@0'
main.o(.text+0xa79):main.cpp: undefined reference to `glClear@4'
main.o(.text+0xa89):main.cpp: undefined reference to `glMatrixMode@4'
main.o(.text+0xa91):main.cpp: undefined reference to `glLoadIdentity@0'
main.o(.text+0xa9b):main.cpp: undefined reference to `glBegin@4'
main.o(.text+0xaaf):main.cpp: undefined reference to `glColor3f@12'
main.o(.text+0xac9):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xae3):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xafd):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xb17):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xb2b):main.cpp: undefined reference to `glColor3f@12'
main.o(.text+0xb42):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xb59):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xb70):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xb87):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xb9b):main.cpp: undefined reference to `glColor3f@12'
main.o(.text+0xbb5):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xbcf):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xbe9):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xc03):main.cpp: undefined reference to `glVertex3f@12'
main.o(.text+0xc0b):main.cpp: undefined reference to `glEnd@0'
C:\minGW\lib/libmingw32.a(main.o)(.text+0x97):main.c: undefined reference to `WinMain@16'
make: *** [assign] Error 1
Linker errors
Author
Hi. I'm trying to compile something that uses SDL and OpenGL, and I'm getting a pile of linker errors - but only for the OpenGL.
The thing is, I'm doing things the hard way - using vim, minGW, and make to glue them together. Here's the output from trying to compile:
The frustrating thing is that those OpenGL library files most definately exist, and g++ is finding them OK - if I put in any bogus libraries it tells me it can't find them (so it's not like it's not searching the directory incorrectly and not reporting errors, or something). Also, manually executing g++ via command prompt has the same effect (so it's not my makefile that's screwy).
Actually, now that I look at that compile log, I notice that it couldn't find the WinMain inserted by SDL either. The thing is, without linking in the SDL libraries it produced several more errors about not being able to find various SDL functions.
The libraries I'm using are those that came with MinGW.
Looks like you're missing the all-important -lmingw32 flag. Try adding that to your linker string.
Ryan
Ryan
Author
Still not working, no change :/
Something else that's frustrating about this is that it compiles, links and runs just fine when I do this under Linux (I'm trying out the whole cross-platform deal). The thing is, the makefile is the same for both, with platform specifics in the relevant included file.
Here's the makefile itself:
winmake:
linmake:
Something else that's frustrating about this is that it compiles, links and runs just fine when I do this under Linux (I'm trying out the whole cross-platform deal). The thing is, the makefile is the same for both, with platform specifics in the relevant included file.
Here's the makefile itself:
PROJECT=assignPROJECT_OBJS=main.o scene.o mathvector.oPLATFORM=windowsBACKUP_LIST = main.cpp scene.h scene.cpp exception.h mathvector.h mathvector.cpp makefile linmake winmakeBACKUP_DIR = backupsall: $(PROJECT)ifeq ($(PLATFORM),windows) include winmakeelse ifeq ($(PLATFORM),linux) include linmake else $(error Do not know how to make for platform "$(PLATFORM)") endifendif##################dependencies#######################%.o: %.cpp $(COMPILER) $(CFLAGS) $*.cpp#####################################################################commandline invocation###############$(PROJECT): $(PROJECT_OBJS) $(LINKER) $(PROJECT_OBJS) -o $(PROJECT)$(EXTENTION).PHONY:clean: $(REMOVE) *.o.PHONY:zip: $(TAR) $(TARNAME) $(SOURCEFILES); $(ZIP) $(TARNAME).PHONY:unzip: $(UNZIP) $(ZIPNAME) $(REDIRECT)####################vim invocation###################.PHONY:buildandrun: $(PROJECT) $(PROJECT)#invoked by F8, in vim..PHONY:rebuild: clean $(PROJECT)#invoked by ctrl+F8 in vim..PHONY:run: $(PROJECT)#invoked by shift+F8.PHONY:backup: $(BACKUP) $(BACKUP_DIR) $(BACKUP_PLAT) $(BACKUP_LIST)winmake:
LFLAGS=-L"C:/minGW/lib" -lmingw32 -lopengl32 -lglaux -lglut32 -lglu32 -lSDLmain -lSDL -mwindows SDL.dllCFLAGS=-I"C:/minGW/include" -I"C:\minGW\include\c++\3.2.3" -I"C:\minGW\include\c++\3.2.3\bits" -I"C:\minGW\include\c++\3.2.3\backward" -I"C:\minGW\include\c++\3.2.3\ext" -I"C:\minGW\include\c++\3.2.3\mingw32\bits" -c COMPILER= C:/minGW/bin/g++.exeLINKER=C:/minGW/bin/g++.exe $(LFLAGS)REMOVE = C:/UnixUtils/usr/local/bin/rm -fTAR = C:/UnixUtils/usr/local/bin/tar -cvvfZIP = C:/UnixUtils/usr/local/bin/gzip UNZIP = C:/UnixUtils/usr/local/bin/tar -xvvzfEXTENTION = .exeBACKUP = C:/UnixUtils/scr/backup.batBACKUP_PLAT=doslinmake:
LFLAGS= -L"/mnt/hdb2/Linux/cg252/sdl/lib" -lSDL -lSDLmain libSDL-1.2.so.0.7.0 /mnt/hdb2/Linux/cg252/opengl/libGL.so /mnt/hdb2/Linux/cg252/opengl/libGLU.so -mconsoleCFLAGS= -I"/mnt/hdb2/Linux/cg252/sdl/include" -cCOMPILER=g++LINKER=g++ $(LFLAGS)REMOVE=rm -fTAR=tar -cvvfZIP=gzip UNZIP= tar -xvvzfEXTENTION =PERL = /usr/bin/perlBACKUP = $(PERL) /mnt/hdb2/Linux/backup.plBACKUP_PLAT = linuxSCP=scp
Well, hm... in your windows make, trying putting the SDL flags first. Especially the -lSDLmain. (Though keep -lmingw32 at the very front.)
The linking order is very important to g++! Mess around with the order, and see if you can come up with a sequence that works.
Ryan
The linking order is very important to g++! Mess around with the order, and see if you can come up with a sequence that works.
Ryan
Author
*sigh*. No change, unfortunately (Can't believe it didn't occur to me to try the same link order as I've got under Linux...)
You think maybe the libraries are bad?
You think maybe the libraries are bad?
EDIT: WAIT I HAD THIS PROBLEM BEFORE I REMEMBER (the problem is not you, nor the libraries - it's that cygwin/mingw is a bit retarded)
The order that Make automagically places it's flags for the default target patterns displeases G++ on Windows for god knows why. Use this basic format:
I have to rewrite the default rules when using default make targets:
edit: don't know why I didn't think of this first post. I guess writing my own basic rules is gotten so built in it's part of my auto-mode.
If this dosn't fit it for you, my original post:
Well, there's allways one way to check if it's a library-order problem:
If that dosn't work, then either there's a messed up header file somewhere which isn't setting up the right tokens for your use, or your library is totally ****ed up.
If it does work, play around with it a little until you get it working (yes you may need to use the -l option for the same library repeatedly - if libA requires libB which requires libA - aka cyclilic dependancies (or however you spell it) - you'd do -lA -lB -lA. Don't ask me, it's how GCC works.
The order that Make automagically places it's flags for the default target patterns displeases G++ on Windows for god knows why. Use this basic format:
g++ (-c) (source files) -o (target file) (LIBRARIES HERE)g++ (-c) (LIBRARIES _NOT_ HERE BAD BAD BAD) (source files) -o (target file)I have to rewrite the default rules when using default make targets:
% : %.o $(LD) $^ -o $@ $(LDFLAGS)# make normally makes it something like $(LD) $(LDFLAGS) $^ -o $@%.o : %.cc $(CC) -c $^ -o $@ $(CCFLAGS)# make normally makes it something like $(CC) $(CCFLAGS) -c $^ -o $@% : %.cc $(LD) $^ -o $@ $(CCFLAGS) $(LDFLAGS)# make normally makes it something like $(LD) $(CCFLAGS) $(LDFLAGS) $^ -o $@edit: don't know why I didn't think of this first post. I guess writing my own basic rules is gotten so built in it's part of my auto-mode.
If this dosn't fit it for you, my original post:
Well, there's allways one way to check if it's a library-order problem:
MakefileLIBS:=-lopengl32 -lglaux -lglut32 -lglu32 -lSDLmain -lSDLLIBS10:=$(LIBS) $(LIBS) $(LIBS) $(LIBS) $(LIBS) $(LIBS) $(LIBS) $(LIBS) $(LIBS) $(LIBS)LDFLAGS:=-L"C:\minGW\lib" -mwindows $(LIBS10)assign.exe : main.o scene.o mathvector.o $(LD) $^ -o $@ $(LDFLAGS)If that dosn't work, then either there's a messed up header file somewhere which isn't setting up the right tokens for your use, or your library is totally ****ed up.
If it does work, play around with it a little until you get it working (yes you may need to use the -l option for the same library repeatedly - if libA requires libB which requires libA - aka cyclilic dependancies (or however you spell it) - you'd do -lA -lB -lA. Don't ask me, it's how GCC works.
Author
Hehehe...
Well, putting the library files last did work. Btw, your suggestion of
"g++ (-c) (source files) -o (target file) (LIBRARIES HERE)" wouldn't have worked (I didn't try it); the -c is telling it to compile only, so it wouldn't be doing any linking (so putting in the libraries does no good). Putting the libraries last when LINKING, however, worked just fine ;)
Thanks for the help, everyone!
Well, putting the library files last did work. Btw, your suggestion of
"g++ (-c) (source files) -o (target file) (LIBRARIES HERE)" wouldn't have worked (I didn't try it); the -c is telling it to compile only, so it wouldn't be doing any linking (so putting in the libraries does no good). Putting the libraries last when LINKING, however, worked just fine ;)
Thanks for the help, everyone!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement