From: Norman V. <nh...@ca...> - 2001-12-15 13:25:56
|
Adam Megacz writes: > >Hey, can anybody here see what I'm doing wrong trying to get this >simple program to link? Hey this question has been answered several times in the last couple of days :-) Link order MATTERS !!! gcc t.c -lgdi32 Cheers Norman >megacz@curry$ /usr/local/cross-gcc/bin/i686-pc-mingw32-gcc -lgdi32 t.c >/tmp/ccRRPJOG.o(.text+0x5f):t.c: undefined reference to >`CreateDIBSection@24' > |
From: Paul G. <pga...@qw...> - 2001-12-16 00:04:39
|
Hi folks, On 15 Dec 2001 at 5:07, Adam Megacz wrote: > > Hey, can anybody here see what I'm doing wrong trying to get this > simple program to link? [skip] > --enable-threads=win32 --enable-sjlj-exceptions Thread model: win32 > gcc version 3.1 20011209 (experimental) > /usr/local/cross-gcc/lib/gcc-lib/i686-pc-mingw32/3.1/cc1 -lang-c -v > -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D_WIN32 > -D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -D__MSVCRT__ -DWINNT > -D_X86_=1 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ > -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__WIN32 -D__WINNT -Asystem=winnt > -D__NO_INLINE__ -D__STDC_HOSTED__=1 -remap -Acpu=i386 -Amachine=i386 > -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ > -D__stdcall=__attribute__((__stdcall__)) > -D__cdecl=__attribute__((__cdecl__)) > -D_stdcall=__attribute__((__stdcall__)) > -D_cdecl=__attribute__((__cdecl__)) > -D__declspec(x)=__attribute__((x)) t.c -quiet -dumpbase t.c -version > -o /tmp/ccXWFdZj.s > GNU CPP version 3.1 20011209 (experimental) (cpplib) (80386, BSD > syntax) GNU C version 3.1 20011209 (experimental) (i686-pc-mingw32) > compiled by GNU C version 3.1 20011207 (experimental). Umm...is there some reason you are trying this cross-compile using an unstable beta release of Mingw Gcc? Nothing wrong with it, was just curious. > ignoring nonexistent directory > "/usr/local/cross-gcc/i686-pc-mingw32/sys-include" #include "..." > search starts here: #include <...> search starts here: > /usr/local/cross-gcc/include > /usr/local/cross-gcc/lib/gcc-lib/i686-pc-mingw32/3.1/include > /usr/local/cross-gcc/i686-pc-mingw32/include > End of search list. > /usr/local/cross-gcc/i686-pc-mingw32/bin/as --traditional-format -o > /tmp/ccB5mY4m.o /tmp/ccXWFdZj.s > /usr/local/cross-gcc/i686-pc-mingw32/bin/ld -Bdynamic > /usr/local/cross-gcc/lib/gcc-lib/i686-pc-mingw32/3.1/../../../../i686 > -pc-mingw32/lib/crt2.o > -L/usr/local/cross-gcc/lib/gcc-lib/i686-pc-mingw32/3.1 > -L/usr/local/cross-gcc/lib/gcc-lib/i686-pc-mingw32/3.1/../../../../i6 > 86-pc-mingw32/lib -lgdi32 /tmp/ccB5mY4m.o -lmingw32 -lgcc -lmoldname > -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc > -lmoldname -lmsvcrt > /tmp/ccB5mY4m.o(.text+0x5f):t.c: undefined reference to > `CreateDIBSection@24' Think you may need to add -mwindows switch as CreateDIBSection is part of wingdi.h. CreateDIBSection is not loaded if -mwindows or -lgdi32 are not set at compile time. Try adding -mwindows switch at compile time (see http://www.mingw.org/docs.shtml for more on "Compiling and Building with Mingw"). Paul G. |
From: Adam M. <mi...@li...> - 2001-12-16 21:29:38
|
"Paul G." <pga...@qw...> writes: > Umm...is there some reason you are trying this cross-compile using > an unstable beta release of Mingw Gcc? Nothing wrong with it, was > just curious. Yes, I'm porting gcj/libgcj (gcc java frontend) to mingw. I have to work against CVS in order to get my patches accepted. - a |
From: John B. <joh...@ho...> - 2001-12-22 19:05:28
|
>Adam Megacz <mi...@li...> writes: > > > Link order MATTERS !!! > > > gcc t.c -lgdi32 > > >Hey, nobody ever answered this... why does the command line order >under mingw, but not unix? Are you certain that the order does not matter on Unix? I have constructed a small example to show that the order does matter. Save the files mylib.h, mylib.c, testmylib.c, and makefile together in a directory. Run make. Run testmylib, which simply calls a function myfunc in libmylib.a. If all is well, you will see: myfunc(2,7) = 9 Now edit the makefile. Change the line that generates testmylib.exe, i.e., gcc -mconsole -o testmylib.exe -L. testmylib.o -lmylib to gcc -mconsole -o testmylib.exe -L. -lmylib testmylib.o The difference is that -lmylib is no longer at the end of the command line; it is now before testmylib.o. run "make clean" to delete all object files, then run "make prog" I guarantee you that it will not link, and you will see: gcc -c -o testmylib.o testmylib.c gcc -c -o mylib.o mylib.c ar -r libmylib.a mylib.o gcc -mconsole -o testmylib.exe -L. -lmylib testmylib.o testmylib.o(.text+0x2a):testmylib.c: undefined reference to `myfunc' make: *** [testmylib.exe] Error 1 It cannot find myfunc because the library that contains it (libmylib.a) is listed before the object file that refers to it (testmylib.o). I have tried this on Linux with gcc 2.95.2 and on NT with gcc 2.95.3-4. You don't have to take my word for it. Try it for yourself on any operating system to which gcc has been ported. It may very well be that gcc does not care about the order of .o files. I leave it as an exercise for you to confirm that. However, object files must be listed before the library files to which they refer, or the references will not be found. Link order MATTERS !!!. /**************** mylib.h *************/ int myfunc(int a, int b); /**************** mylib.h *************/ /**************** mylib.c *************/ #include "mylib.h" int myfunc(int a, int b){ return a+b; } /**************** mylib.c *************/ /************** testmylib.c *************/ #include <stdio.h> #include "mylib.h" int main(int argc, char *argv[]) { printf("myfunc(2,7) = %i\n", myfunc(2,7)); return 0; } /************** testmylib.c *************/ ############### makefile ################# CC=gcc prog: testmylib.exe lib: libmylib.a # libmylib.a: mylib.o ar -r libmylib.a mylib.o libmylib.o: mylib.c gcc -o mylib.o -c mylib.c # testmylib.exe: testmylib.o libmylib.a gcc -mconsole -o testmylib.exe -L. testmylib.o -lmylib clean: del *.exe del *.o del *.a ############### makefile ################# _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
From: Adam M. <mi...@li...> - 2001-12-15 13:41:40
|
"Norman Vine" <nh...@ca...> writes: > Hey this question has been answered several times > in the last couple of days :-) So sorry... I checked the FAQ.... really, I swear =) Perhaps somebody could add this to the FAQ? > Link order MATTERS !!! > gcc t.c -lgdi32 Strange... is this a mingw thing? I've never stopped to think about link order when linking unix binaries, and this has never caused me problems before.... maybe I've just been tremendously lucky. - a |
From: Adam M. <mi...@li...> - 2001-12-22 09:38:35
|
Adam Megacz <mi...@li...> writes: > > Link order MATTERS !!! > > gcc t.c -lgdi32 > > Strange... is this a mingw thing? I've never stopped to think about > link order when linking unix binaries, and this has never caused me > problems before.... maybe I've just been tremendously lucky. Hey, nobody ever answered this... why does the command line order under mingw, but not unix? - a |