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=651431

Yes, my Python is a framework built, as seems to be neccessary 
to run wxWindows.
So that stops it working it seems.

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.