Metapkg:compilation problems
From the Fink Wiki
The C Preprocessor
I'm getting weird #pragma lines in places I shouldn't!
Apple's GCC 3.3 as of a few weeks before Panther release has a bug in which pragma lines get spit out when they shouldn't. Generally you should be able to fix this by using "cpp3" instead of "cpp" or "gcc3 -E" instead of "gcc -E".
I get an "unknown compiler" error in TargetConditionals.h when trying to use a header from a framework with cpp
The C preprocessor gets hints from gcc as to how to run when using headers from Apple frameworks. Try setting $(CPP) to "gcc -E" instead of "cpp".
I'm getting errors in code that isn't even used!
The preprocessor on gcc-3.3 is much stricter, so even things inside an #if or #ifdef block where the test is not true can cause build failures. This can be fixed by either removing the offending code, or using the -traditional-cpp flag. -traditional-cpp has other problems though.
It's complaining about NOERROR not being defined
NOERROR comes from the bind8 headers (see "Headers" below). Add -DBIND_8_COMPAT to the CPPFLAGS.
Headers
I get type errors when using <sys/mman.h>
You must include <sys/types.h> before including <sys/mman.h> [1]
I'm getting errors with arpa or inet headers relating to DNS resolution
You may need to set -DBIND_8_COMPAT to get them to compile (alternately, you could port the code to use the newer bind-9 compatible routines).
I'm getting conflicting type errors when compiling math.h for symbols like acos
You may need to add -lmx to your LDFLAGS. Some packages check for symbols like acosf, which have prototypes in math.h, but only link with -lmx.
Linking
I'm getting errors about missing _res_* symbols. What happened?
The DNS resolution code is updated in panther, you need to add "-lresolv" to the link line.
I'm getting missing symbols like acosf
You may need to add -lmx to your LDFLAGS. Some packages check for symbols like acosf, which have prototypes in math.h, but only link with -lmx.
It is linking against the wrong lib
If you specify -lfoo Apple's linker, by default, searches through every linker path, looking for libfoo.dylib, then starts again looking for libfoo.a if it didn't find a dylib. If you are trying to link a static archive and a dynamic library with the same name is instaled, it will always find the dylib. New with panther and gcc-3.3 is the -search_paths_first flag, which makes ld take the first matching library name. Since gcc does not currently understand this flag, it must be specified as "-Wl,-search_paths_first". If you are not sure that your problems are caused by getting the incorrect library, you can check what ld is loading by using the -whyload flag to ld.
I'm getting "illegal reference for -dynamic code" when linking
This is caused by a mismatch between strong and weak symbols in the libraries and object code (usually brought on by STL or exception-handling code, or explicitly using weak symbols in your code). The workaround is to compile your code with "-fno-coalesce". For more info, see the darwin-development list archives. (Sadly, the relevant messages from 2003 are no longer archived as of July 2006).
I'm getting undefined symbols for "__environ" when linking
_environ is defined in /usr/lib/crt1.o which is only linked into applications. If you are building a library you must look up the symbol at runtime. You can either use the native calls for loading symbols (or the dlsym emulation layer in dlcompat and Panther's libSystem), or you can include crt_externs.h and do "#define environ (*_NSGetEnviron())". Alternatively you could, on panther, link the library with "-undefined dynamic_lookup".
I'm getting undefined symbols but they are defined dammit
if the link has static libraries that define the symbols that ld is telling you are "undefined", use nm to check if they are common symbols (denoted by a ' C ' in nm's output). If that is the case, it is likely that the only symbols required from the .o at link time are the common symbols, and since they do not appear in the archive table of contents, they are not found by ld. Either add -fno-common to the C{PP}FLAGS or set RANLIB="ranlib -c" to fix this. ranlib -c will put the common symbols in the table of contents, -fno-common will eliminate common symbols, putting the symbols in the table of contents for the archive. Gotta love apple's tools :)
