Recently I discovered ccache and am very happily using it.

However, some Python extensions (python-ldap, to be
precise) didn't link correctly, ignoring
runtime_library_dirs, only if I used ccache.
(CC='ccache gcc' python setup.py...)

Attached patch fixes this by treating any compiler with
string gcc or g++ in it as GCC, not only those start
with gcc or g++. This feels like hack over hack, but oh
well.

Logged In: YES 
user_id=837148

Hye-Shik Chang pointed out that Intel C Compiler(icc) needs
-Wl,-R as well, not -R. Perhaps this should check for icc too?

Logged In: YES 
user_id=1269204

Patch is good, bug still exists and not limited to just 
ccache users.

On many systems using gcc, 'CC' does not == "gcc".

For example, on this 
system /usr/lib/python2.4/config/Makefile reads
'CC=i686-pc-linux-gnu-gcc -pthread'

Therefore distutils will never link the RPATH/RUNPATH into 
the .so correctly.
If any of the libraries linked against are in directories 
that are not in the system's LDPATH, then the application 
will fail when it cannot find the linked library.

This is a part of Gentoo Python patchset.
http://gentoo.osuosl.org/distfiles/python-gentoo-patches-2.5.1.tar.bz2

NOTE: See also issue1032 which has a patch for this.

Can we come to a consensus on which one has the best patch?

I've attached a patch, based on the original, that will fix distutils
for both GCC and ICC.

I've updated my patch to resemble the patch from issue1032 and also
because profiling showed that using str.__contains__ is more efficient
than using str.find.

any() built-in is new in 2.5. PEP 291 specifies 2.3 compatibility for
distutils. (tarek: Why?) The original patch used str.find because
backward-compatibility requirement used to be stricter.

Seo, This ticket specifies Python-2.6 as the only version so using "any"
didn't seem to be a problem. 
I was not aware of PEP 291 until you mentioned it and, in order to
maintain compatibility with Python-2.3, the generator expression would
have to be dispensed with as well.

Raymond, I would prefer to substitute "max" for "any" in this case as it
seems to be more straightforward. There's no performance benefit to
using "min" as both "min" and "max" are O(n), no?

min() is a substitute for all() and
max() is a substitute for any().

They are O(n) but do not have the early
out behavior of any() and all().

The patch file is against distutils, should the title be changed to reflect that?

Mark, I’d say no, since the component field is already set. Actually, if you find reports that have distutils in the title but not as component, it would be helpful to set the right component. Thanks.

I’m in favor of committing the patch. I don’t like that it has no tests, but in this case I guess we have to rely on the documentation and just trust it will do the Right Thing™.

Re: compatibility, the reason is that people want to use distutils from a given stable version to package or install projects with older Pythons.