Bugs item #640553, was opened at 2002-11-19 05:04
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640553&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nick Maclaren (nmm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misuse of /usr/local/in setup.py
Initial Comment:
I cannot guarantee that this has not been reported
before, as the search facility doesn't appear
sufficiently powerful to determine that, and I do not
have time to read a hundred bug reports.
setup.py forces the use of /usr/local, which is wrong
on more counts
than I can describe. Not merely need it not exist, it
could easily
contain the wrong versions of libraries and headers.
The following
change should be reversed:
*** setup.py.org Mon Nov 18 19:57:09 2002
--- setup.py Mon Nov 18 19:57:23 2002
***************
*** 197,207 ****
return platform
def detect_modules(self):
- # Ensure that /usr/local is always used
- if '/usr/local/lib' not in
self.compiler.library_dirs:
- self.compiler.library_dirs.insert(0,
'/usr/local/lib')
- if '/usr/local/include' not in
self.compiler.include_dirs:
- self.compiler.include_dirs.insert(0,
'/usr/local/include' )
try:
have_unicode = unicode
--- 197,202 ----
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 17:12
Message:
Logged In: YES
user_id=752496
Deprecated. Reopen only if still happens in 2.3 or newer.
. Facundo
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-08 02:23
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
. Facundo
----------------------------------------------------------------------
Comment By: Nick Maclaren (nmm1)
Date: 2002-11-19 14:44
Message:
Logged In: YES
user_id=652073
Well, that's an odd interpretation, but it isn't a great
matter. However, I do feel that the "gotcha" should be
documented. For example, the following perfectly reasonable
use will fail horribly on many systems:
A user version of a shareable library is in /usr/local/lib,
which
is a mountable filing system, and a system version in
/usr/lib,
which isn't - the former may be a symlink, or may be the
testing
version. Python is built using the standard mechanism, and
is
then used for system scripts. If those are then ever run
when
/usr/local is not mounted, they will fail horribly.
Incidentally, we got caught by that one by making /usr
mountable on one version of IRIX. It was actually SGI
themselves who had missed the "gotcha", but we had the
problem :-(
Do what you will with this - I have resolved the issue
here.
----------------------------------------------------------------------
Comment By: Skip Montanaro (montanaro)
Date: 2002-11-19 14:38
Message:
Logged In: YES
user_id=44345
Some compilers complain if -I/usr/local/include is on the command line because
it
changes the compiler's notion of include file search order. The case
-L/usr/local/lib
may be similar. If this was an ideal world, I think we would ask the compiler
if it
searches /usr/local by default. If so, don't add the -I/-L flags. Maybe
there's an
autoconf macro floating around that can do this?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-19 14:05
Message:
Logged In: YES
user_id=21627
If /usr/local/lib causes a build failure, then the
requirements are not absolutely standard, by (our)
definition: We require /usr/local/lib to provide any
libraries that are not normally on the system. Absence of
/usr/local/lib is not a problem, nor are missing libraries a
problem.
If accessing /usr/local/lib alone causes catastrophic
failures, it can't be a standard system.
----------------------------------------------------------------------
Comment By: Nick Maclaren (nmm1)
Date: 2002-11-19 09:29
Message:
Logged In: YES
user_id=652073
No, that's not the issue. The build was absolutely out of
the box, and the requirements were absolutely standard.
But, for reasons that are irrelevant, -L/usr/local/lib
caused failure.
The point was that I had not specified it, it was not
specified anywhere in the configuration or any of the
Makefiles, and it wasn't even in Modules/Setup! So I
could not understand where it was being set.
I discovered that setup.py is invoked by default, and that
did the job but didn't leave a record in any configuration
or building file. GOTCHA!
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-11-19 07:00
Message:
Logged In: YES
user_id=6656
It's not added if it doesn't exist in the HEAD branch.
Wrt the other complaint, I think setup.py is only intended
to be a convenience. If you have even vaguely complex
building requirements, edit Modules/Setup instead.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640553&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
