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
distutils build_ext fails to set library_dirs in 2.7.2 on Linux #60530
Comments
Hi, when trying to build extension modules with distutils I ran into gcc -pthread -shared -L build/temp.linux-x86_64-2.7/h5py/defs.o -L/reg/g/psdm/sw/external/hdf5/1.8.4p1/x86_64-rhel6-gcc44-opt/lib -L. -Wl,-R/reg/g/psdm/sw/external/hdf5/1.8.4p1/x86_64-rhel6-gcc44-opt/lib -lhdf5 -lpython2.7 -o build/lib.linux-x86_64-2.7/h5py/defs.so For some reason location of the python library is not added to the I tracked the reason down to a particular environment that we have, if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
# building third party extensions
self.library_dirs.append(sysconfig.get_config_var('LIBDIR'))
else:
# building python standard extensions
self.library_dirs.append('.') apparently sys.executable in our case refers to a symlink path, while I think fix for our case should be easy (I can't say about other cases Andy |
Would you like to work on a patch? |
I never submitted any patch to Python, but unless somebody more |
Great! http://docs.python.org/devguide contains all the info needed to get the code and make a patch. If you apply your suggestion to the code and it fixes your build, I will commit it. A small unit test to check the new behavior of build_ext and avoid regressions will be needed, but it’s not always easy to write these tests, so depending on your time I will be able to provide guidance or write the test myself. |
Hi Éric, I am attaching a patch that fixes the problem. The patch is tiny, basically 1-line. This replaces the direct use of sys.executable with the symlink-resolved version of the same path. I made the change for linux/unix platforms and also for cygwin/atheos (I'm sure cygwin has symlinks, not sure if atheos does but resolving symlinks can't hurt in general). The patch was created from default hg branch (3.4.0a0 I guess), I have built it and tested in my simple setup. The problem that we have (in 2.7) is indeed reproducible without this patch and it is fixed with this patch applied. Concerning the unit test - I'm not sure how to write one but if you have suggestions I could try. The complications in this case are that python needs to be installed in its configured location and the symlink needs to be created outside python install directory which points to the installed interpreter. If unit test could handle this then it might be possible. I did not update any documentation, could not find any place to mention this change. Sure you will know better what else is needed to be updated. I'd be happy to help you with whatever else is necessary to commit this patch. Cheers, |
Vinay, do you think dereferencing sys.executable could lead to trouble with venvs? |
It could - the venv code looks for a venv configuration file relative to sys.executable, which could be a symlink into a system-wide Python installation. Resolving the symlink would mean that the venv can't be found. |
OK, I see the problem. Do you think it would help if it tested both
Alternatively one can reverse the test. I guess that 'else:' is supposed Andy |
In terms of the venv code, I don't see how doing the test in that way would cause problems - as long as the value of sys.executable doesn't change, then as I see it, the venv code should operate as it's meant to. |
FTR a patch in bpo-18976 is said to also fix this one. |
Given that bpo-18976 was said to have fixed this and is now closed as "fixed", and every tagged version is now EOL, I'm closing the issue. |
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: