> Hello, > > I have a question about a valid C code. I am trying to compile > the following code in MacOSX (*). I don't understand what the > problem is ? Could someone please explain me what is going on ? > Since I declare the variable with extern I should not need to pass > -fno-common, right ? > > Thanks for your help > Mathieu > > foo.h: > extern int bar[]; > > foo.c: > int bar[4 * 256]; > > And compile lines are: > $ gcc -o foo.o -Wall -W -fPIC -c foo.c > $ gcc -dynamiclib -o libfoo.dylib foo.o > ld: common symbols not allowed with MH_DYLIB output format with the > -multi_module option > foo.o definition of common _bar (size 4096) > /usr/bin/libtool: internal link edit command failed > > using gcc 3.3 20030304 (Apple Computer, Inc. build 1671)
This is not a problem with GCC. In fact, it is not a problem at all. It is a misunderstanding of the linker. When you run gcc -dynamiclib -o libfoo.dylib foo.o it really does libtool -dynamic -o libfoo.dylib foo.o which becomes ld -dylib -o libfoo.dylib foo.o However, -multi_module is the default, so it really is ld -dylib -o libfoo.dylib foo.o -multi_module -multi_module is enabled by default, so you can get errors from the linker of the form `libfoo.dylib(foo.o)' when there's a link problem. The error happens because a) an `extern' variable is called a `common variable' b) in multipule module mode, common variables are not allowed c) if they were allowed, it would defeat the purpose of that option: better diagnostics To fix it, add -Wl,-single_module to the end of the GCC command line. However, note that subsequent linker errors will refer to `libfoo.dylib' instead of `libfoo.dylib(foo.o)'. Samuel Lauber -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
