argument order in cygwin gcc 4.3 matters when linking with glib-2.0
I am trying to compile code that works on os x and linux using cygwin. However, I am finding that the argument order to gcc gives unanticipated results.
For example, the follo开发者_开发技巧wing fails:
gcc -std=gnu99 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lglib-2.0 -lintl -liconv -fgnu89-inline -fno-leading-underscore -o nb-learn.exe nb-learn.c
but the following works:
gcc -std=gnu99 -fgnu89-inline -fno-leading-underscore -o nb-learn.exe nb-learn.c -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lglib-2.0 -lintl -liconv
Can someone explains how this works? Also, are there techniques or code I can look at for getting autoconf to change the argument order depending on the platform?
Here are the first two lines of the error message:
/cygdrive/c/Users/aischein/AppData/Local/Temp/cc9MvUsf.o:nb-learn.c:(.text+0x260): undefined reference to `_g_hash_table_size'
/cygdrive/c/Users/aischein/AppData/Local/Temp/cc9MvUsf.o:nb-learn.c:(.text+0x29c): undefined reference to `_g_hash_table_get_keys'
Thanks,
SetJmp (gcc 4.3.4)
GCC documentation says:
-l
library
-l
librarySearch the library named library when linking. (The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified.
Thus, `
foo.o -lz bar.o
' searches library `z
' after filefoo.o
but beforebar.o
. Ifbar.o
refers to functions in `z
', those functions may not be loaded.
-Wl,--start-group
and -Wl,--end-group
options are useful sometimes for avoiding such problems.
All this isn't a problem if you use only shared libraries.
精彩评论