It's impossible to specify more than one external library to link using 
build_ext --libraries.  Bug 716634 says that the problem is fixed, but it isn't.    
Assuming that the desired format is --libraries="lib1 lib2 etc", then there's a 
simple one line fix which I've attached. 

The problem exists in python 2.3.5, 2.4.1, 2.4.2 and in cvs HEAD. 

Another bug day task

This one is really annoying. Could you please consider fixing this one for the next release? (=lightweight change)

Distutils is frozen and we fix only bugs. This case is a little bit at the edge. 

Can you show us an example of a call you are trying to make, and the gcc command line output that fails ? 

I want to see if we can find a workaround. If so, this will be changed only in Distutils2. If not I'll change this to a bug and we'll fix it in distutils too.

I applied the patch proposed by slanger. This one is working.
Now, I'm executing this instruction to build my extension:
"%pythonRoot%\python.exe" setup.py build_ext --include-dirs "C:\MyApp\include" --library-dir "C:\MyApp\lib" --libraries "myLib1 myLib2"
If I don't use the patch, then the error I get is 'unresolved external symbol _xxx referenced in function _abc'. Which is quite normal since I can only point to one library...

Since "--libraries" is plural, and since the help text says:

--libraries (-l)     external C libraries to link with

it should IMO be considered a bug.

(Standard UNIX linkers have a different convention: you can specify -l several times in order to link against several libraries; however, distutils seems to ignore all but the last -l option)

I agree this is a bug: it’s a broken feature, not a new one, even if it can be argued that fixing a long-standing behavior enables new usages, and is thus comparable to a new feature.

I found no mention of --libraries in the docs, so I looked at the file history, and it’s clear that the intent of the code does not match its behavior.  The fix is simple:

-        if isinstance(self.libraries, str):
-            self.libraries = [self.libraries]
+        self.ensure_string_list('libraries')

I guess Greg forgot to change that line of code when he invented the ensure_* methods.  No test is broken by this change.  Do we need a regression test for this?  It’s not strictly required IMO.

FTR, in distutils2, I want to make the types and formats clear for everything.  For example, build_ext.swig_opts is defined as “a list” in the current docs, this time with an example that shows it’s space-separated (“--swig-opts="-modern -I../include"”).  The code does not use ensure_string_list, and hence does not support comma-separated.  IMO, any value described as list should accept space-separated and comma-separated.  This is probably out of scope for distutils, but something I definitely want to improve in distutils2.  Supporting multiple options (-lm -lfoo) is IMO feasible too.

I’ve reviewed other modules for the same error and found two candidates: config.libraries, the same thing as build_ext.libraries, and install.extra_path, for which I’m not sure.

(More distutils2 thoughts: A number of options are split on os.pathsep, a new ensure_dirs_list method looks in order.  Regarding the type system, an angry comment in build_py confirmed the need :)