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: Misuse of /usr/local/in setup.py
Type: Stage:
Components: Build Versions: Python 2.7, Python 2.6, Python 2.5, Python 2.2
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: facundobatista, loewis, mwh, nmm1, sable, skip.montanaro
Priority: normal Keywords:

Created on 2002-11-19 08:04 by nmm1, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Messages (10)
msg13370 - (view) Author: Nick Maclaren (nmm1) Date: 2002-11-19 08:04
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 ----
msg13371 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-11-19 10:00
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.
msg13372 - (view) Author: Nick Maclaren (nmm1) Date: 2002-11-19 12:29
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!

msg13373 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-11-19 17:05
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.
msg13374 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2002-11-19 17:38
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?
msg13375 - (view) Author: Nick Maclaren (nmm1) Date: 2002-11-19 17:44
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.
msg13376 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2005-01-08 05:23
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
msg13377 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2005-05-30 20:12
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo
msg128606 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-15 16:56
This bug is still present in Python 2.7.1. I have also just been beaten by it on solaris.

I have libintl.so.1 in /usr/lib and libintl.so.8 in /usr/local/lib.

I have never specified that I wanted to use /usr/local/lib anywhere, but the compilation scripts insist on linking _locale.so with libintl.so.8, which may not be available on the platforms where I will deploy my python binaries.

/usr/local/lib should only be used if it is explicitly specified in LDFLAGS in my opinion.
msg128607 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-15 17:05
I can only bypass this by explicitly specifying -L/usr/lib so that it will take precedence over -L/usr/local/lib.

But this behavior is still broken...
"Explicit is better than implicit."
I can see no reason why /usr/local should be implicitly added; people that really need it can always do export LDFLAGS="$LDFLAGS -L/usr/local/lib"
History
Date User Action Args
2022-04-10 16:05:55adminsetgithub: 37499
2011-02-15 17:05:35sablesetnosy: mwh, loewis, skip.montanaro, facundobatista, nmm1, sable
messages: + msg128607
2011-02-15 16:56:36sablesetnosy: + sable

messages: + msg128606
versions: + Python 2.6, Python 2.5, Python 2.7
2002-11-19 08:04:25nmm1create