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
_sysconfigdata.py wrong on AIX installations #62435
Comments
_sysconfigdata.py includes information about how to build extension modules. On AIX this requires a wrapper script to build shared libraries. The file includes definitions like: 'BLDSHARED': './Modules/ld_so_aix gcc -pthread -bI:./Modules/python.exp', which is correct in the build directory, but is not correct for the install directory. The paths do not correspond to the installed location of ld_so_aix and makexp_aix in lib/pythonX.Y/config . |
This is the cause of the failures in test_distutils. |
Can you suggest how to fix this? |
It looks like someone already tried to fix part of this, but reversed the assignment diff -r a089a8b1f93d Lib/sysconfig.py
--- a/Lib/sysconfig.py Fri Jun 21 18:37:02 2013 -0400
+++ b/Lib/sysconfig.py Fri Jun 21 22:33:15 2013 -0700
@@ -368,7 +368,7 @@
# -- these paths are relative to the Python source, but when installed
# the scripts are in another directory.
if _PYTHON_BUILD:
- vars['LDSHARED'] = vars['BLDSHARED']
+ vars['BLDSHARED'] = vars['LDSHARED']
# There's a chicken-and-egg situation on OS X with regards to the
# _sysconfigdata module after the changes introduced by python/cpython#59503: BLDSHARED is relative to srcdir and LDSHARED is relative to the install directory BINLIBDEST. LDSHARED= |
Patch against current trunk |
With my patch applied, _sysconfig.py looks like 'BLDSHARED': '/usr/local/lib/python3.4/config/ld_so_aix gcc -pthread ' |
Ha, that code dates back to 2000 and 2001 (f1e40abbedb3 and c958678720fd, respectively). |
New changeset c554194240fc by Antoine Pitrou in branch '3.3': New changeset e3ac917fcf9c by Antoine Pitrou in branch 'default': |
Committed the patch. I trust you that you got it right! |
I think I see the source of the confusion. test_distutils fails because it runs in the build tree and without files installed. The test does not use the installed version of sysconfig, so it looks for ./Modules/ld_so_aix, which fails. The kludge from 2000 was trying to make the test work. But after installation, the kludge defines variables incorrectly to build Modules after Python is installed. Because the distutils test is testing in tree and not the installed version of Python, it is not testing what the end user will experience. I am unsure about the best way to make the test pass. |
Actually, ld_so_aix is autogenerated from ld_so_aix.in into builddir, while makexp_aix is not. Attached patch eventually might fix the test too? |
+1 |
Kindly ping. Do you prefer another report for the aix-absbuilddir patch as this one is already closed? |
Do you want me to open a new issue or do you want to open a new issue? |
Erm, question target was the python committers. And I'd create the new issue if they prefer. |
issue#10656 is the out-of-source part already. |
Hmm... instead of reversing the order while keeping in _generate_posix_vars(), feels like it would have been better to move the code from 2000 back to _init_posix() where it originally was, without changing the order - because now for sysconfig within Python build, the working B-value of LDSHARED is lost. Something like (note the function names): --- a/Lib/sysconfig.py Fri Jun 06 01:23:53 2014 -0500
+++ b/Lib/sysconfig.py Fri Jun 06 17:11:02 2014 +0200
@@ -364,11 +364,6 @@ def _generate_posix_vars():
if hasattr(e, "strerror"):
msg = msg + " (%s)" % e.strerror
raise OSError(msg)
- # On AIX, there are wrong paths to the linker scripts in the Makefile
- # -- these paths are relative to the Python source, but when installed
- # the scripts are in another directory.
- if _PYTHON_BUILD:
- vars['BLDSHARED'] = vars['LDSHARED']
# There's a chicken-and-egg situation on OS X with regards to the
# _sysconfigdata module after the changes introduced by python/cpython#59503:
@@ -409,6 +404,11 @@ def _init_posix(vars):
# _sysconfigdata is generated at build time, see _generate_posix_vars()
from _sysconfigdata import build_time_vars
vars.update(build_time_vars)
+ # On AIX, we have different paths for building the Python modules
+ # relative to the Python source, and building third party modules
+ # after installing the Python dist.
+ if _PYTHON_BUILD:
+ vars['LDSHARED'] = vars['BLDSHARED']
def _init_non_posix(vars):
"""Initialize the module as appropriate for NT""" |
FWIW - this doesn't appear to have been backported to v2.7.x. As a result, the ./Modules/ld_so_aix reference still exists in _sysconfigdata.py in v2.7.8 (and therefore I was unable to build numpy). The workaround is easy enough, it is just something that is worth noting. |
It might have been good to get this reopened to attract more attention to it. Anyway, bpo-28311 has now been opened for 2.7, and it seems to be about the same problem. |
Reopening this to fix the original bug in 2.7, and to improve things for Python 3. Michael Felt (or anyone else): Can you confirm if Michael Haubenwallner’s suggested patch from <https://bugs.python.org/issue18235#msg219888\> is appropriate? It looks like that patch won’t apply directly to 2.7, but the spirit of that patch looks sensible to me for Python 2 and 3. I.e. don’t mess with the variables in _generate_posix_vars(), which writes them to a data file, but overwrite LDSHARED in _init_posix(), which happens at run time. |
Michael, Are you suggesting to move the code fragment *AND* revert or change the reversal of LDSHARED? The Python code seems to be setting and reversing the value in multiple places. This also relates to bpo-25825. Repeatedly flipping this around is not making progress. |
I am not suggesting anything. I am only trying to report what I experience. The first observation was that I could not build python when src != build directory. I believe that was the original complaint as well. The second observation came when I tried to use pip install, and also make of the mercurial "addition". That module consistently failed until I editted, manually, the _sysconf*.py file to make LDwhatever the same as LDCXXwhatever. With study I could figure out what they stand for - I would guess they are related, if not derived from, to some "autotool" conventions. To be honest, I do not understand what is meant by "flipping", so I am neither for nor against. For me to test a patch - which I am very willing to do - I would be grateful for the mercurial command(s) to test it normally (now that I finally have it working - I figured out how to make the SSL part work this evening). In short, please do not shoot me, the messenger :) |
Michael Felt, The patch was from Michael Haubenwallner. I was addressing Michael Haubenwallner. |
The value that works for LDSHARED is the value that LDCXXSHARED has. 'BLDSHARED': './Modules/ld_so_aix xlc_r -bI:./Modules/python.exp 'LDCXXSHARED': '/opt/lib/python2.7/config/ld_so_aix xlc_r except neither BLDSHARED nor LDCXXSHARED have taken the extra LDFLAG In short: LDSHARED needs to be a full path, not relative and should LDCXXSHARED should also add LDFLAGS -L entries (and perhaps, where BLDSHARED does not work when "builddir" is . and source_dir is On 15-Oct-16 00:23, Martin Panter wrote:
|
correction: On 23-Oct-16 20:54, Michael Felt wrote:
|
Michael F.: It sounds like you have three separate but related problems:
|
Regarding out-of-tree builds (Problem 3), see bpo-10656, which already has a potential patch. |
As this is the issue still open with regard to issues with ld_so_aix... The current release Python3-3.5.2 does not include ld_so_aix in the "make install DESTDIR=xxx output ("make install" also neglects to install ld_so_aix) Installation Summary So, the last two variables are correct - BLDSHARED is not correct in _sysconfigdata.py because the file does not exist during the build process. However, the build succeeds, so apparently this value for BLDSHARED is not used during the build. |
FYI: after manually creating the .../libpython3.5/config directory and copying three files (see below) I was able to "pip3 install cython" as test. At the packing area: in the package: Results: +-----------------------------------------------------------------------------+ installp: APPLYING software for: Restoring files, please wait. +-----------------------------------------------------------------------------+ Installation Summary root@x064:[/data/prj/python3/python3-3.5.2]export OBJECT_MODE=64 root@x064:[/data/prj/python3/python3-3.5.2]pip3 install cython Question: if there is a patch since 3.5.2 was released - how do I pick this up in order to test (and maybe patch)? I am a bit lost in the hg/git discussion about where to go to get current status. |
OK - just looked at what happens with Python3-3.6 new file name: _sysconfigdata_m_aix5_.py values: The 'build' worked, so I am guessing that BLDSHARED had a different value that what it shows here. The full pathname for ld_so_aix is correct. As I mentioned in https://bugs.python.org/issue28311#msg277692 - still broken for Python2-2.7(.13) - shall try your patch above (once I figure out how to grab it) |
The "key" bit of the patch is to move the code AND make this assignment: if _PYTHON_BUILD:
vars['LDSHARED'] = vars['BLDSHARED'] Besides, imho, skipping around the problem that LDSHARED is not correctly assigned - it cannot work because BLDSHARED is not set to the 'installed' value. And, frankly I am amazed (in Python3-3.6.0) both are equal AND both pointing at the 'installed' location. OOPS: I just looked and the patch above is NOT in the Python3-3.6 branch, and as both variables are identical now in _sysconfigdata_m_aix5.py - neither assignment has any affect. Again: comparing python2 and python3 it seems the latest Python3 now have the fullpath - and equal definitions - for both variables WHILE Python2 use 'relative' pathnames - BUT both are equal. As far as the patch goes - it is irrevalant and can be removed in Python3 while a quick hack for Python2 would be to use (in the new location!) if _PYTHON_BUILD:
vars['LDSHARED'] = vars['LDCXXSHARED'] Details: |
So are you saying you tried patching Python 2 and/or 3, but did not see any relevant change at all? |
I did not go through a whole build process. Changing: if _PYTHON_BUILD:
vars['BLDSHARED'] = vars['LDSHARED']
to
if _PYTHON_BUILD:
vars['LDSHARED'] = vars['BLDSHARED'] is not going to help if both variables are wrong in _sysconfigdata*.py Also, The patch is not applied in any version - yet the values in _sysconfigdata*.py are different, i.e., version dependent (without the patch). If I errored in my assumption that the file being patched is reading _sysconfigdata*.py then I will need to patch and build from scratch to see the effect on _sysconfigdata.py |
Michael, you need to build from scratch. The values are set and tweaked in various phases of configure and then written to _sysconfigdata.py for installation. The values in the file reflect the values used during the build, but many of them are not used in an installed version of Python. Three important phases are:
The initial configuration scripts must match the location where the export files will be installed. And the _sysconfigdata.py definitions used to build external modules in an installed version of Python must refer to the proper location. All of the pieces are interconnected and must be tested in a wholistic manner. A partial rebuild does not test the impact of the patch. |
Ok. I shall rebuild from scratch. When I do, I start from a "clean" system - only the compiler and my mkinstallp helper script. I am adding the latest zlib for what I would package but I shall forgoe that for this test. |
This is "only" for Python-2.7 (for now). The others will be tested as I am able. Working with the patch submitted 2013-10-19 (aka https://bugs.python.org/file32229/issue18235.patch) A) Without/before the patch: root@x064:[/data/prj/python/Python-2.7.13.0]grep LDSHARED ./build/lib.aix-5.3-2.7/_sysconfigdata.py B) Apply the patch:
diff -r 0a26ef834a49 Lib/sysconfig.py
--- a/Lib/sysconfig.py Sat Oct 19 14:24:44 2013 +0200
+++ b/Lib/sysconfig.py Sat Oct 19 11:46:10 2013 -0700
@@ -368,7 +368,7 @@
# -- these paths are relative to the Python source, but when installed
# the scripts are in another directory.
if _PYTHON_BUILD:
- vars['LDSHARED'] = vars['BLDSHARED']
+ vars['BLDSHARED'] = vars['LDSHARED'] After the patch: root@x064:[/data/prj/python/Python-2.7.13.0]grep LDSHARED ./build/lib.aix-5.3-2.7/_sysconfigdata.py Which makes me think - maybe NOTHING is needed - as 'BLDSHARED' should be Modules/ld_so_aix, Rather than actual deletes: commented out to (after patch was applied) C: if: statement and assignment - commented out
diff -ru Python-2.7.13/Lib/sysconfig.py Python-2.7.13.0/Lib/sysconfig.py
--- Python-2.7.13/Lib/sysconfig.py 2016-12-17 20:05:06 +0000
+++ Python-2.7.13.0/Lib/sysconfig.py 2017-01-23 14:39:31 +0000
@@ -310,8 +310,8 @@
# On AIX, there are wrong paths to the linker scripts in the Makefile
# -- these paths are relative to the Python source, but when installed
# the scripts are in another directory.
- if _PYTHON_BUILD:
- vars['LDSHARED'] = vars['BLDSHARED']
+# if _PYTHON_BUILD:
+# vars['BLDSHARED'] = vars['LDSHARED'] root@x064:[/data/prj/python/Python-2.7.13.0]grep LDSHARED ./build/lib.aix-5.3-2.7/_sysconfigdata.py So, perhaps the best patch 'today', versus what may have been best in 2013 - is to remove the 5 lines starting with # On AIX, ... |
If the assignment is completely removed, won’t this break the test when run from the source or build tree (as opposed to when installed)? Or at least make the situation worse: the AIX buildbot is already failing test_distutils, but at least it is looking for Modules/ld_so_aix locally rather than in the yet-to-be-installed location. |
I completely agree with Martin's concern. As I expressed before, this needs to work in three contexts:
|
You guys are the experts. I can only comment on what I see. IMHO: the file _sysconfigdata.py is more accurate with nothing in it. I am clearly confused by whatever process this is. If you believe it is more accurate to have the BLD variable 'inaccurate' in this file - and that we just need to "believe" that it has the correct value during the build (which, starting with version 2.7.13 seems to be the case, as I am able to build in a different directory - and could not do this with version 2.7.10 (first time I tried using separate directories). In short, I have no expert opinion on this. My naive view is that both variables being accurate in the file is more accurate. In any case, the patch is needed for a working _sysconfigdata.py and integration with something such as "pip build ...". Only after I learned about 'pip' did I ever run into this, i.e., only people who are trying to install something extra have issues here. I have been 'patching' _sysconfigdata.py manually so that things work normally. I hope my feedback helps you move forward on this. |
Reading the ticket, it seems that there is some confusion about what LDSHARED and BLDSHARED are used for. BLDSHARED is used to override the LDSHARED value when building libpython and the shared modules (via setup.py). LDSHARED is what is meant to be used for building shared modules after installation. This distinction is not being followed by all targets in the Makefile, but is needed in cases where special build tools are necessary, as is the case on AIX. For the latter, BLDSHARED has to point to the source tree version of those build tools, while LDSHARED has to point to the installed version of these. On AIX, BLDSHARED should therefore point to the ./Modules/ld_so_aix (or better: the absolute dir of the source tree), while LDSHARED needs to point to the installation target for ld_so_aix, e.g. /usr/local/lib/python2.7/config/ld_so_aix. So the fix which was already applied to 3.4 is correct for 2.7 as well. The missing part is the fix to the configure script, since in Python 2.7, this still uses relative paths: BLDSHARED="Modules/ld_so_aix \$(CC) -bI:Modules/python.exp"
LDSHARED="\$(BINLIBDEST)/config/ld_so_aix \$(CC) -bI:\$(BINLIBDEST)/config/python.exp" instead of the ones from 3.4:
|
Hmm, looking at the patch again: diff -r a089a8b1f93d Lib/sysconfig.py
--- a/Lib/sysconfig.py Fri Jun 21 18:37:02 2013 -0400
+++ b/Lib/sysconfig.py Fri Jun 21 22:33:15 2013 -0700
@@ -368,7 +368,7 @@
# -- these paths are relative to the Python source, but when installed
# the scripts are in another directory.
if _PYTHON_BUILD:
- vars['LDSHARED'] = vars['BLDSHARED']
+ vars['BLDSHARED'] = vars['LDSHARED']
# There's a chicken-and-egg situation on OS X with regards to the
# _sysconfigdata module after the changes introduced by python/cpython#59503: I think that with the configure fix, the special case for AIX can be dropped altogether. It just polishes over the bug in configure, turning a relative path into an absolute one. |
BTW: Does the ticket still apply to 3.5+ ? From reading the ticket, it seems that the problem is already fixed for those versions. |
I don’t run AIX, but my understanding is there are three distinct branches (2.7, 3.5, and 3.6+). Some of the following is guessed, so please correct me if I am wrong: Python 2.7: Python 3.5: Python 3.6+: Marc-Andre, regarding configure.ac and absolute vs relative paths, I suggest you open a separate bug. That is an orthogonal issue, and this bug is already too complicated. But also keep in mind bpo-18235. You want the build tree, not the source tree. Also, if you mean to drop the assignment in sysconfig, I think that will break in-tree usage of sysconfig (3.5+) and distutils (3.6+), unless Python happens to also be installed. |
Sorry I meant bpo-10656. I recently committed a fix regarding out-of-tree builds and ld_so_aix, and it sounds like you were thinking of reverting that. |
re: msg286115,
** the tarball for Python-2.7.13 is building from ../src/Python-2.7.13/configure where as ../src/Python-2.7.12/configure and the earlier (ones I tried) were not. ** However, 'make distclean' is not working.
** Is this as simple as (from the 'build directory': ** shall check this later, make test in general seems to be working - is test_distutils a specific test you want verified? Now reading the other comments from last night... re: 286172 and 286173 Short response: I shall download and check the latest Python-3.{4|5|6} and report back. |
As far as bpo-10656 and this issue are concerned: Python-3.4 is out of context (but 3.4.6 was just released) - and does not work with 'out of tree' builds. The other versions: 2.7.13, 3.5.3 and 3.6.0 do build out-of-tree. Notes: FYI: regarding build and src in different directories Not working... unable to execute '../src/Python-3.4.6/Modules/ld_so_aix': No such file or directory Concludes with: root@x064:[/data/prj/python/Python-3.4.6]find . -name _sysconfigdata.py -ls -exec grep LDSHARED {} \; +++++++ Working ++++++++ Working: 2.7.13 -- Note: the 'lines' in sysconfig.py are removed: Working: 3.5.3 Working: 3.6.0 -- Note new file name!! |
On 24.01.2017 15:23, Michael Felt wrote:
I'm not sure what you mean with "out of tree". When building
This is strange: where does the "../src/Python-3.4.6/Modules/ld_so_aix"
BLDSHARED should be fixed to use an absolute path, I guess.
Here BLDSHARED is wrong, but shouldn't do any harm since
This looks odd and like a regression. Again, the path PS: The BLDSHARED setting in sysconfig is not really relevant. |
I am back at this: (note: short answer to msg277745 - No. does not work for me) As ... expressed before, this needs to work in three contexts:
Below are results of 'in tree' and 'out of tree' testing. in/out seems to have no (more) impact. But - same issue - ld_so_aix is not found. (notice the "src" in string of 'threading.py') Now, back to 'in tree' with patch from msg219888 (no "src" in path) root@x064:[/data/prj/python/Python-2.7.13]find . -name _sysconfigdata\*.py -ls -exec grep LDSHARED {} \; Conclusion: The .dist file is from the source tarball from last december for 2.7.13 michael@x071:[/data/prj/python/src]diff -u Python-2.7.13/Lib/sysconfig.py.dist> - # On AIX, there are wrong paths to the linker scripts in the Makefile
- # -- these paths are relative to the Python source, but when installed
- # the scripts are in another directory.
- if _PYTHON_BUILD:
- vars['LDSHARED'] = vars['BLDSHARED']
-
# There's a chicken-and-egg situation on OS X with regards to the
# _sysconfigdata module after the changes introduced by python/cpython#59503:
# get_config_vars() is called by get_platform() as part of the
@@ -355,6 +349,11 @@
# _sysconfigdata is generated at build time, see _generate_posix_vars()
from _sysconfigdata import build_time_vars
vars.update(build_time_vars)
+ # On AIX, there are wrong paths to the linker scripts in the Makefile
+ # -- these paths are relative to the Python source, but when installed
+ # the scripts are in another directory.
+ if _PYTHON_BUILD:
+ vars['LDSHARED'] = vars['BLDSHARED'] def _init_non_posix(vars):
"""Initialize the module as appropriate for NT""" |
OK - so details on the failing tests - for the record only. However, I would appreciate some 'expert' feedback on what is expected to be happening in this test: ====================================================================== Traceback (most recent call last):
File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_sysconfig.py", line 102, in test_sysconfig_compiler_vars
self.assertEqual(global_sysconfig.get_config_var('LDSHARED'), sysconfig.get_config_var('LDSHARED'))
AssertionError: 'Modules/ld_so_aix xlc_r -bI:Modules/python.exp' != '/opt/lib/python2.7/config/ld_so_aix xlc_r -bI:/opt/lib/python2.7/config/python.exp' BULK details... ====================================================================== Traceback (most recent call last):
File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_install.py", line 216, in test_record_extensions
cmd.run()
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/install.py", line 563, in run
self.run_command('build')
File "/data/prj/python/Python-2.7.13/Lib/distutils/cmd.py", line 326, in run_command
self.distribution.run_command(command)
File "/data/prj/python/Python-2.7.13/Lib/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build.py", line 127, in run
self.run_command(cmd_name)
File "/data/prj/python/Python-2.7.13/Lib/distutils/cmd.py", line 326, in run_command
self.distribution.run_command(command)
File "/data/prj/python/Python-2.7.13/Lib/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", line 340, in run
self.build_extensions()
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", line 449, in build_extensions
self.build_extension(ext)
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", line 531, in build_extension
target_lang=language)
File "/data/prj/python/Python-2.7.13/Lib/distutils/ccompiler.py", line 691, in link_shared_object
extra_preargs, extra_postargs, build_temp, target_lang)
File "/data/prj/python/Python-2.7.13/Lib/distutils/unixccompiler.py", line 202, in link
raise LinkError, msg
LinkError: command '/opt/lib/python2.7/config/ld_so_aix' failed with exit status 1 ====================================================================== Traceback (most recent call last):
File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_config_cmd.py", line 46, in test_search_cpp
match = cmd.search_cpp(pattern='xxx', body='/* xxx */')
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/config.py", line 206, in search_cpp
src, out = self._preprocess(body, headers, include_dirs, lang)
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/config.py", line 129, in _preprocess
self.compiler.preprocess(src, out, include_dirs=include_dirs)
File "/data/prj/python/Python-2.7.13/Lib/distutils/unixccompiler.py", line 113, in preprocess
raise CompileError, msg
CompileError: command 'xlc_r' failed with exit status 40 ====================================================================== Traceback (most recent call last):
File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_build_ext.py", line 63, in test_build_ext
cmd.run()
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", line 340, in run
self.build_extensions()
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", line 449, in build_extensions
self.build_extension(ext)
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", line 531, in build_extension
target_lang=language)
File "/data/prj/python/Python-2.7.13/Lib/distutils/ccompiler.py", line 691, in link_shared_object
extra_preargs, extra_postargs, build_temp, target_lang)
File "/data/prj/python/Python-2.7.13/Lib/distutils/unixccompiler.py", line 202, in link
raise LinkError, msg
LinkError: command '/opt/lib/python2.7/config/ld_so_aix' failed with exit status 1 ====================================================================== Traceback (most recent call last):
File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_build_ext.py", line 292, in test_get_outputs
cmd.run()
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", line 340, in run
self.build_extensions()
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", line 449, in build_extensions
self.build_extension(ext)
File "/data/prj/python/Python-2.7.13/Lib/distutils/command/build_ext.py", line 531, in build_extension
target_lang=language)
File "/data/prj/python/Python-2.7.13/Lib/distutils/ccompiler.py", line 691, in link_shared_object
extra_preargs, extra_postargs, build_temp, target_lang)
File "/data/prj/python/Python-2.7.13/Lib/distutils/unixccompiler.py", line 202, in link
raise LinkError, msg
LinkError: command '/opt/lib/python2.7/config/ld_so_aix' failed with exit status 1 ====================================================================== Traceback (most recent call last):
File "/data/prj/python/Python-2.7.13/Lib/distutils/tests/test_sysconfig.py", line 102, in test_sysconfig_compiler_vars
self.assertEqual(global_sysconfig.get_config_var('LDSHARED'), sysconfig.get_config_var('LDSHARED'))
AssertionError: 'Modules/ld_so_aix xlc_r -bI:Modules/python.exp' != '/opt/lib/python2.7/config/ld_so_aix xlc_r -bI:/opt/lib/python2.7/config/python.exp' Ran 194 tests in 3.254s FAILED (failures=1, errors=4, skipped=21)
Traceback (most recent call last):
File "test_distutils.py", line 18, in <module>
test_main()
File "test_distutils.py", line 13, in test_main
test_support.run_unittest(distutils.tests.test_suite())
File "/data/prj/python/Python-2.7.13/Lib/test/test_support.py", line 1494, in run_unittest
_run_suite(suite)
File "/data/prj/python/Python-2.7.13/Lib/test/test_support.py", line 1477, in _run_suite
raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred
root@x064:[/data/prj/python/Python-2.7.13/Lib/test] |
I have a (large) patch that completely eliminates the need for ld_so_aix and makeexp_aix. I've applied and been using this with for Python 2.7 and 3.5+, but I still need to go back and validate the tests to ensure everything passes as expected. It's still a work in progress, but the patch can be found at ericvw@e889f5f. If this is out of context for this particular issue, I'm happy to raise a new issue to have a focus discussion about potentially landing this. Ignore changes for README.AIX since I am addressing that in bpo-28845. I believe if we can eliminate the wrapper scripts, it will simplify the build and linking for AIX for the interpreter and C-extension modules. |
On 24.01.2017 16:47, Eric N. Vander Weele wrote:
Hmm, the patch seems to be incomplete, as it just removes Please note that building with both xlc_r and gcc needs to
Please open a new issue for this to discuss this change there.
Sure, if that's possible. The scripts are rather old and AIX FWIW: They still do work without any problems, provided the |
The new changes to accommodate for the script removal are in ericvw@e889f5f#diff-e2d5a00791bce9a01f99bc6fd613a39dR9159 and ericvw@e889f5f#diff-67e997bcfdac55191033d57a16d1408aR2403.
I'll need to double check gcc, I have it working with xlc_r already.
Absolutely, I'll clean up the patch and provide more details for the changes in another issue. Thanks. |
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: