Os X 10.2.6. Python 2.3b2 from http://homepages.cwi.nl/~jack/ macpython.html#beta Trying to comiple py-xml-rpc 2.8.3 from http:// sourceforge.net/projects/py-xmlrpc/ I get a ton of multiple defined symbols like: ld: multiple definitions of symbol _rpcBase64Type build/temp.darwin-6.6-Power_Macintosh-2.3/src/rpcBase64.o definition of _rpcBase64Type in section (__DATA,__data) build/temp.darwin-6.6-Power_Macintosh-2.3/src/ rpcBoolean.o definition of _rpcBase64Type in section (__DATA,__common) ld: multiple definitions of symbol _rpcBoolType ..... I tracked this down to the presence of the compile flag "- fno-common" used by the distutils. The man page for gcc states quite clearly that this is not usually an advisable flag, quote: -fno-common In C, allocate even uninitialized global variables in the data section of the object file, rather than gen- erating them as common blocks. This has the effect that if the same variable is declared (without "extern") in two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the pro- gram will work on other systems which always work this way. I have compiled and linked all files with the makefile that is also distributed in py-xmlrpc, but I had to change the link options to "-flat_namespace -undefined warning". I can help in testing a fix if someone can assist with distutils knowledge. Torsten
Logged In: YES user_id=44345 Works for me (python setup.py install ; python -c 'import xmlrpc'). I don't see -fnocommon in the gcc flags. This is with a Unix-style build of Python, not a framework build.
Logged In: YES user_id=45365 While I don't remember why the -fno-common is there in the first place I don't dare to take it out before 2.3: the fact that the framework build has it while the normal build doesn't have it suggests that there is a good reason for it. And I think that having a 2.3 framework built with -fno-common means that it can't even go out for 2.3.X, although I'm not 100% sure about that one (-fno-common definitely can't be added at a micro-release). But: I cant imagine that this can't be fixed at the pyxml side of things. Unix is the only platform I know that has this "common" idea, on old-Mac and Windows you always have to put "extern" in front of every declaration but one. So pyxml probably has a compile time define that adds the necessary magic.