-
-
Notifications
You must be signed in to change notification settings - Fork 29.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cannot find -lpythonX.X when building Python on FreeBSD with --enable-shared #48616
Comments
I get a number of "cannot find -lpython2.5" error when building Python This is how you can reproduce this problem. cd Python-2.5.2 and you will get gcc -shared You can workaround this by running ./configure LDFLAGS="-L." |
Please try this patch with a clean source tree. It adds the current Index: setup.py --- setup.py (revision 67295)
+++ setup.py (working copy)
@@ -245,6 +245,7 @@
def detect_modules(self):
# Ensure that /usr/local is always used
add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
+ add_dir_to_list(self.compiler.library_dirs, '.')
add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')
|
Christian's patch fixed this problem! I'm not sure why the other platforms don't suffer this problem. |
Since r53691, and bpo-1600860, "." is added to library_dirs on Linux The critical point to notice is that the -L option is not only while Now, the question is how to extend this approach to FreeBSD. For 2.5 and For the trunk, and probably 3.0, I would try to add the library whenever |
Changing the title because this is not 2.5.x specific. |
Changing the title again because this problem is not FreeBSD 4 specific. |
2.5.3 is out of scope for this issue (and thus, the whole of 2.5). There |
Martin,
|
No. It should be dealt with in the same way as on Linux (or the Linux
Not yet, no. However, they are soon to be released, so chances are low |
A more appropriate patch should be (for 2.7 trunk - I'm grabbing a checkout of 3.2 trunk now): Index: build_ext.py --- build_ext.py (revision 77388)
+++ build_ext.py (working copy)
@@ -280,7 +280,7 @@
# Python's library directory must be appended to library_dirs
sysconfig.get_config_var('Py_ENABLE_SHARED')
if ((sys.platform.startswith('linux') or sys.platform.startswith('gnu')
- or sys.platform.startswith('sunos'))
+ or sys.platform.startswith('sunos') or sys.platform.startswith('freebsd'))
and sysconfig.get_config_var('Py_ENABLE_SHARED')):
if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
# building third party extensions I'm hoping someone will weigh in on whether this should be done on all versions of FreeBSD (I don't see why not, but perhaps there is some magic that I don't understand in newer versions). |
configure.in has the same action for NetBSD*|FreeBSD*|DragonFly*, so I think distutils should parallel that. Not sure what sys.platform would be on the other BSDs, though. |
NetBSD is netbsd* and DragonFly is dragonfly* (currently dragonfly2, although I suspect in this way dragonfly1 was identical, if it ever existed). |
Confirming identical failures on all branches: tip: /usr/bin/ld: cannot find -lpython3.4m Tested attached patch with success, will carry this patch locally in all FreeBSD Python ports until it merged. Let's close this 5 year old nasty :) |
Why special-case FreeBSD in the patch? Shouldn't this be done for nearly all Unix systems? (or, at the very least or BSD-likes)? |
Concur, and then also, why special case linux, gnu and sunos? The comment is: # Python's library directory [[must]] be appended to library_dirs (emphasis mine) Is the real question then "in what cases should the library path NOT be added?" ? I also note Christian used a different approach (#msg76118), electing to unconditionally add the path in setup.py |
Attaching an initial patch with the following changes:
This results in all platforms receiving the same treatment as the default, which is consistent with the comment |
Koobs, have you signed a contributor's agreement? |
New changeset 48d28de5bdf8 by Antoine Pitrou in branch '3.3': New changeset d6e35146ae53 by Antoine Pitrou in branch 'default': New changeset 28e6c23c8ae6 by Antoine Pitrou in branch '2.7': |
Ok, let's mark this bug fixed. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: