This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: GCC detection for runtime_library_dirs when ccache is used
Type: compile error Stage: resolved
Components: Build, Distutils Versions: Python 3.1, Python 3.2, Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: tarek Nosy List: eric.araujo, jafo, jkankiewicz, loewis, rhettinger, rickharris, sanxiyn, steve.dower, tarek
Priority: normal Keywords: patch

Created on 2005-08-09 04:53 by sanxiyn, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
distutils-rpath-gcc.diff sanxiyn, 2005-08-09 04:54
distutils-rpath-gcc_and_icc.patch jkankiewicz, 2009-06-10 00:28 Patch Lib/distutils/unixccompiler.py to issue "-Wl,-R" for Intel C/C++ also
distutils-rpath-gcc_and_icc.patch jkankiewicz, 2009-06-10 18:24 2.3-compatible patch for Lib/distutils/unixccompiler.py to issue "-Wl,-R" for Intel C/C++ also
Messages (14)
msg48650 - (view) Author: Seo Sanghyeon (sanxiyn) Date: 2005-08-09 04:53
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.
msg48651 - (view) Author: Seo Sanghyeon (sanxiyn) Date: 2005-08-09 07:08
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?
msg48652 - (view) Author: Rick (rickharris) Date: 2006-07-01 01:41
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.
msg48653 - (view) Author: Seo Sanghyeon (sanxiyn) Date: 2007-05-25 03:52
This is a part of Gentoo Python patchset.
http://gentoo.osuosl.org/distfiles/python-gentoo-patches-2.5.1.tar.bz2
msg55954 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2007-09-17 07:29
NOTE: See also issue1032 which has a patch for this.

Can we come to a consensus on which one has the best patch?
msg89175 - (view) Author: Jason Kankiewicz (jkankiewicz) Date: 2009-06-10 00:07
I've attached a patch, based on the original, that will fix distutils
for both GCC and ICC.
msg89176 - (view) Author: Jason Kankiewicz (jkankiewicz) Date: 2009-06-10 00:28
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.
msg89178 - (view) Author: Seo Sanghyeon (sanxiyn) Date: 2009-06-10 00:46
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.
msg89222 - (view) Author: Jason Kankiewicz (jkankiewicz) Date: 2009-06-10 18:24
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?
msg89223 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-06-10 18:33
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().
msg114545 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-08-21 19:03
The patch file is against distutils, should the title be changed to reflect that?
msg114547 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-08-21 19:10
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.
msg114549 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-08-21 19:18
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.
msg386426 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-02-03 18:30
Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools
History
Date User Action Args
2022-04-11 14:56:12adminsetgithub: 42263
2021-02-03 18:30:35steve.dowersetstatus: open -> closed

nosy: + steve.dower
messages: + msg386426

resolution: out of date
stage: patch review -> resolved
2014-02-03 19:47:57BreamoreBoysetnosy: - BreamoreBoy
2010-08-21 19:18:49eric.araujosetassignee: loewis -> tarek
messages: + msg114549
2010-08-21 19:10:18eric.araujosetnosy: + eric.araujo
messages: + msg114547
2010-08-21 19:03:30BreamoreBoysetversions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6
nosy: + BreamoreBoy

messages: + msg114545

stage: patch review
2009-06-10 18:34:00rhettingersetmessages: - msg89179
2009-06-10 18:33:42rhettingersetmessages: + msg89223
2009-06-10 18:24:43jkankiewiczsetfiles: + distutils-rpath-gcc_and_icc.patch

messages: + msg89222
2009-06-10 02:11:35alexandre.vassalottilinkissue1032 superseder
2009-06-10 01:43:13rhettingersetnosy: + rhettinger
messages: + msg89179
2009-06-10 00:46:03sanxiynsetmessages: + msg89178
2009-06-10 00:28:42jkankiewiczsetfiles: + distutils-rpath-gcc_and_icc.patch

messages: + msg89176
2009-06-10 00:25:15jkankiewiczsetfiles: - distutils-rpath-gcc_and_icc.patch
2009-06-10 00:07:17jkankiewiczsetfiles: + distutils-rpath-gcc_and_icc.patch
nosy: + jkankiewicz
messages: + msg89175

2009-02-16 16:30:09akitadasetnosy: + tarek
2008-01-12 05:25:46christian.heimessettype: compile error
components: + Build
versions: + Python 2.6, - Python 2.5
2007-09-17 07:29:30jafosetassignee: loewis
messages: + msg55954
nosy: + loewis, jafo
2005-08-09 04:53:25sanxiyncreate