Issue640553
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.
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) | 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) * | 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) * | 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) * | 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) * | 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:55 | admin | set | github: 37499 |
2011-02-15 17:05:35 | sable | set | nosy:
mwh, loewis, skip.montanaro, facundobatista, nmm1, sable messages: + msg128607 |
2011-02-15 16:56:36 | sable | set | nosy:
+ sable messages: + msg128606 versions: + Python 2.6, Python 2.5, Python 2.7 |
2002-11-19 08:04:25 | nmm1 | create |