argument order in cygwin gcc 4.3 matters when linking with glib-2.0

Question

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 following 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)

Answer 1

GCC documentation says:

-llibrary

-l library

Search 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 libraryz' after file foo.o but before bar.o. If bar.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.