On 27 Jun 2008, at 17:50, Jane wrote: > g++ -I/opt/local/include -O2 -D_THREAD_SAFE -D_REENTRANT -DMEMWATCH > -Wall -Winline -Wpointer-arith -Wcast-qual -Wcast-align -ggdb -I/ > opt/local/include -L/opt/local/lib /opt/local/lib/libfltk_gl.a - > framework AGL -framework OpenGL /opt/local/lib/libfltk.a -lpthread - > framework Carbon -framework ApplicationServices -L/opt/local/lib - > lportmidi -lporttime -o prodatum memwatch.o prodatum-debug.o > prodatum-midi.o prodatum-data.o prodatum-ctrl.o prodatum-wid.o > prodatum-grps.o prodatum-ui.o prodatum-main.o
Link order: You *must* list all the objects that use a LIB, before you list the LIB itself - otherwise, as the linker scans the libs, it might decide that no one has asked for a specific function, so doesn't bother to link it in. When your object later *does* need that function... So... always objects then libs, and if the libs have dependencies they'd better be in the right order too! Actually, Im surprised you hadn't encountered that one before? There is (or at least used to be) an option you can pass to gcc/ld that will cause it to recurse the libs until all the symbols are resolved or really not found, that might work for you, but it does slow things down a lot, and means you have less control over the link order... -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
