[issue36721] Add pkg-config python-3.8-embed and --embed to python3.8-config
Change by Michael Haubenwallner : -- pull_requests: +13592 pull_request: https://github.com/python/cpython/pull/737 ___ Python tracker <https://bugs.python.org/issue36721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)
Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com> added the comment: Within this context, the "svr4" label originates in the "-bsvr4" AIX linker flag, and actually is another (yet fully documented by the ld(1) man page) method for creating shared libraries on AIX to support filename based shared library versioning, which is known as the DT_SONAME tag with the ELF binary format. For details please refer to the GCC install doc: https://gcc.gnu.org/install/configure.html#WithAixSoname -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue26439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)
Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com> added the comment: Although I'm unable to double check for the moment, feels like the "SVR4" support still is incomplete: Remember that even the libNAME.so file may be an archive, or a symlink to an archive, with the real Shared Object as member having the F_LOADONLY flag set and usually named shr.o or shr_64.o, besides an Import File shr.imp or shr_64.imp, which actually is used at linktime and referring to the real Shared Object: This is necessary to emulate the "DT_SONAME" feature seen with ELF shared libraries. For reference, please have a look at the shared libraries created by recent libtool when --with-aix-soname=svr4 configure option is set. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue26439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs
Changes by Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>: -- pull_requests: +652 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15590> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19521] Parallel build race condition on AIX since python-2.7
Changes by Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>: -- pull_requests: +560 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19521> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)
Michael Haubenwallner added the comment: Let's switch to github-based patches to discuss about: https://github.com/python/cpython/compare/2.7...haubi:issue27435/2.7 For the library search path I prefer to use loadquery(L_GETLIBPATH), available via new _ctypes_aix module now, but also used with L_GETINFO in Python/dynload_aix.c already. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)
Michael Haubenwallner added the comment: On 02/03/2017 09:52 PM, Michael Felt wrote: >> Anyway: >> Unfortunately, there is no concept of embedding something like ELF's >> DT_SONAME tag into the Shared Object. >> The very (PATH,BASE,MEMBER) value as (specified to and) discovered by the >> linker is recorded into the just-linked executable (or Shared Object). >> This implies that the runtime loader does search for the very same filename >> (and member eventually) as the linker (at linktime). > > I assume this is why there are many systems besides AIX that do not > support/use DT_SONAME. Except for Windows, I'm not sure which "many systems besides AIX" you're talking here about, that "do not use/support DT_SONAME". > At least I see many references to "Shared > Objects" libFOO.so.X.Y.Z, libFOO.so.X.Y, libFOO.so.X and libFOO.so (with > the latter three being symbolic links to the first). When a system happens to find these symlinks useful, then it actually _does_ support embedding DT_SONAME (or something similar) into its binary file format. > Another issue is support for what I believe MacOS calls "fat" objects - > that support both 32-bit and 64-bit applications - rather than /XXX/lib > for 32-bit objects and /XXX/lib/lib64 or /XXX/lib64 for 64-bit objects. Yes, the AIX Archive Libraries supporting different bitwidths for members is quite similar to MacOS fat objects. However - although related, the creation of "fat" AIX archives is a different topic. But yes, Python ctypes.find_library+dlopen should know how to deal with them. > b) One of the difficulties I faced is trying to guess what version -lFOO > should find when there is more than one version available. Exactly. There is an idea below (the symbol->member map). >> But still, how to get ctypes.find_library() working - ideally for each >> variant, is another story. Right now it does not work for any variant, > Do you mean all systems, or specific to AIX - I am assuming you mean AIX. Yes - find_library currently does not work for any variant on *AIX*. >> but I guess that search algorithm should follow how the linker discovers the >> (PATH,BASE,MEMBER) values to > I am not a tool builder. My comments are based on observations and > experience from when I was a developer 25+ years ago. The AIX linker is > not interested in the member name - it seems to go through the > PATH/libBASE.a looking for the first object it can find to resolve a > symbol. The name of the object it finds becomes the MEMBER it records in > it's internal table of where to look later when the application runs. Exactly. >> write into just-linked executables, combined with how the runtime loader >> finds the Shared Object to actually load. > I worked on a patch - to do all that - taking into consideration the way > libtool names .so files/members and then looking into/at "legacy" aka > IBM dev ways they did things before the libtool model was so prominent. > > My algorithm - attempts to solve the (PATH, BASE, MEMBER) problem as > "dynamically" as possible. PATH and BASE are fairly straight forward - > but MEMBER is clearly more complex. > > PATH: start by looking at the python executable - As far as I can tell, any executable can actually link against the Python interpreter. > and looking at it's "blibpath" - There also is the loadquery() subroutine in AIX, see https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.basetrf1/loadquery.htm loadquery(L_GETLIBPATH) "Returns the library path that was used at process exec time.", which includes both the environment variable LIBPATH (or LD_LIBRARY_PATH if LIBPATH is unset) and the executable's "blibpath" value. > and using that as the default colon separated list of PATHs Question is if we do want to consider _current_ values of environment variable LIBPATH (or LD_LIBRARY_PATH) in addition to the "library path at process exec time"? > to search for BASE.a archive. Once a BASE.a file is found it is examined > for a MEMBER. If all PATH/BASE.a do not find a potential MEMBER then the > PATHs are examined again for PATH/BASE.so. Erm, nope, the AIX linker has a different algorithm (for -lNAME): Iterating over the "library path", the first path entry containing any matching filename (either libNAME.a or libNAME.so) will be used, and no further library path iteration is performed. This one found PATH/filename does have to provide the requested symbol in one way or another. > When a .so file is found that > is returned - versioning must be accomplished via a symbolic link to a > versioned library. The linker does not perform such a check, nor does it feel necessary for
[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)
Michael Haubenwallner added the comment: Feels like it is up to me to shed some light on various topics here: AIX defines (static) "Object" files and "Shared Object" files. Both can (but do not need to) be members of an "Archive Library". When talking about (dynamically loading) a "shared library" on non-AIX systems, the correct wording for AIX is (dynamically loading) a "Shared Object" - independent of whether it is a standalone file or an archive member. As you already agreed on, ctypes.util.find_library() indeed should return the location of the Shared Object - as either "/path/to/file" or "/path/to/file(member)". And ctypes.CDLL() should add the RTLD_MEMBER flag to _ctypes.dlopen() if there is the "(member)" part. However, that does not necessarily mean the RTLD_MEMBER value needs to be available through the ctypes API. Instead, RTLD_MEMBER feels more appropriate for the _ctypes API - and on AIX only. Anyway: Unfortunately, there is no concept of embedding something like ELF's DT_SONAME tag into the Shared Object. The very (PATH,BASE,MEMBER) value as (specified to and) discovered by the linker is recorded into the just-linked executable (or Shared Object). This implies that the runtime loader does search for the very same filename (and member eventually) as the linker (at linktime). However, to still get some kind of shared library versioning, multiple versions of one Shared Object are put into one single Archive Library, where the "old" versions get the LOADONLY flag set (via 'strip -e') - so executables linked against an old version still can load their "old" Shared Object, while the linker discovers the "current" version only. But this "single-filename" based shared library versioning is a huge burden for packages managers - either human or software, even when they maintain their packages in a private prefix (like /opt/freeware, /usr/local and similar). Neither can they put their "current" Shared Object's version into the single (system's) Archive Library, nor can they mark existing Shared Objects as LOADONLY. On the other hand, they also do not want to pull all the system versions into their own Archive Library. So for package managers it is crucial to have "multi-filename" based shared library versioning instead. But there is help: AIX also provides (plain text) "Import Files": They contain a list of symbols for the linker, and a (PATH,BASE,MEMBER) tuple naming the Shared Object that provides these symbols at runtime. So yes, Import Files can be used for "multi-filename" based shared library versioning. Thus, libtool now offers the "--with-aix-soname=svr4" configure flag, where "libNAME.so.X" really is created as an Archive Library, containing the Shared Object "shr.o" with the LOADONLY flag set, and the Import File "shr.imp" referring to "libNAME.so.X(shr.o)" for runtime. Combined with the symlink "libNAME.so", for the "-lNAME" argument the linker discovers the Import File "libNAME.so(shr.imp)" now, while recording "libNAME.so.X(shr.o)" into the executable for the runtime loader. Note that for 64bit the Shared Object and Import File is named "shr_64.o" and "shr_64.imp", respectively. While libtool's "--with-aix-soname=svr4" variant creates "libNAME.a" from static Objects only, both libtool's "--with-aix-soname=aix" and "--with-aix-soname=both" - for backwards compatibility - create "libNAME.a" for traditional "single-filename" based versioning: Without any static Object - as even Shared Objects can be linked statically(!). But to statically link the Shared Object (as an archive member), neither the LOADONLY flag must be set, nor an Import File must be found (as Import Files cannot serve for static linking). And "--with-aix-soname=aix", libtool still creates standalone "libNAME.so.X.Y.Z" along the (versioning-wise useless) symlinks. So it is up to the package manager which "aix-soname" variant to choose within its prefix: For example, in Gentoo Prefix I'm using "--with-aix-soname=svr4" only. But still, how to get ctypes.find_library() working - ideally for each variant, is another story. Right now it does not work for any variant, but I guess that search algorithm should follow how the linker discovers the (PATH,BASE,MEMBER) values to write into just-linked executables, combined with how the runtime loader finds the Shared Object to actually load. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)
Changes by Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>: -- nosy: +haubi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)
Changes by Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>: -- nosy: +haubi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10656] "Out of tree" build fails on AIX
Michael Haubenwallner added the comment: Modules/python.exp is generated at build-time, thus does not belong to $(srcdir). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
Michael Haubenwallner added the comment: ...a long time since I've been in this area... David, I'm not completely sure which code fragments you're talking about for "revert or change". Anyway: If I remember correctly, the confusion here is about the idea behind LDSHARED and BLDSHARED. As far as I understand, this idea originally was: LDSHARED: The "command to create shared modules". Used as variable in the "Makefile (and similar) templates to build python modules" for both in-python and third party modules. Initialized to hold the value which works for third party modules to link against the _installed_ python. BLDSHARED: Read as "Buildtime-LDSHARED". Holds the value to override LDSHARED with while building python itself (_PYTHON_BUILD=True), which works for building in-python modules to link against the _builddir_ python. So there's no point in ever setting BLDSHARED to the value of LDSHARED. Actually there is no point in having BLDSHARED visible at all in an installed python, nor using its value while building third party modules - there's just no code yet that prunes BLDSHARED from the installed _sysconfigdata.py. HTH, /haubi/ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19521] parallel build race condition on AIX since python-3.2
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: +251 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10656] Out of tree build fails on AIX
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: +252 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16189] ld_so_aix not found
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: +253 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16189 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
Michael Haubenwallner added the comment: 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 #15298: @@ -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 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs
Michael Haubenwallner added the comment: For AIX, with both these configure variants: $ configure --prefix=/prefix --enable-shared CC=gcc CXX=g++ OPT= $ configure --prefix=/prefix --enable-shared --without-computed-gotos CC=xlc_r CXX=xlC_r OPT= the output changes like this: $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4 old: -L/prefix/lib -lpython3.4m new: -L/prefix/lib -lpython3.4m -Wl,-bE:/prefix/lib/python3.4/config-3.4m/python.exp -lld $ /prefix/bin/python3.4-config --ldflags old: -L/prefix/lib -lintl -ldl -lm -lpython3.4m -Wl,-bE:Modules/python.exp -lld new: -Wl,-bI:/prefix/lib/python3.4/config-3.4m/python.exp For Linux, with this configure variant: $ configure --prefix=/prefix --enable-shared CC=gcc CXX=g++ the output changes like this: $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4 old: -L/prefix/lib -lpython3.4m new: -L/prefix/lib -lpython3.4m -Xlinker -export-dynamic $ /prefix/bin/python3.4-config --ldflags old: -L/prefix/lib -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic new: # Yes, nothing. Not sure if python modules should have undefined python symbols, or link against libpython.so Just found out that distutils.command.build_ext.get_libraries() does add libpython.so for Linux and similar (not Darwin and AIX). Actually, distutils.command.build_ext.get_libraries() should add $LINKFORMODULE instead now, so LDSHARED does not need to carry. More thoughts? (will post results with --disable-shared as separate comment) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15590 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs
Michael Haubenwallner added the comment: Now for --disable-shared: For AIX, with both these configure variants: $ configure --prefix=/prefix --disable-shared CC=gcc CXX=g++ OPT= $ configure --prefix=/prefix --disable-shared --without-computed-gotos CC=xlc_r CXX=xlC_r OPT= the output changes like this: $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4 old: -L/prefix/lib -lpython3.4m new: -L/prefix/lib -lpython3.4m -Wl,-bE:/prefix/lib/python3.4/config-3.4m/python.exp -lld $ /prefix/bin/python3.4-config --ldflags old: -L/prefix/lib/python3.4/config-3.4m -L/prefix/lib -lintl -ldl -lm -lpython3.4m -Wl,-bE:Modules/python.exp -lld new: -Wl,-bI:/prefix/lib/python3.4/config-3.4m/python.exp For Linux, with this configure variant: $ configure --prefix=/prefix --enable-shared CC=gcc CXX=g++ the output changes like this: $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4 old: -L/prefix/lib -lpython3.4m new: -L/prefix/lib -lpython3.4m -Xlinker -export-dynamic $ /prefix/bin/python3.4-config --ldflags old: -L/prefix/lib/python3.4/config-3.4m -L/prefix/lib -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic new: # Yes, nothing. And with --disable-shared, even distutils.command.build_ext.get_libraries() does *not* add libpython.so for Linux and similar, so python-shipped modules are linked with python symbols undefined now - but still as shared libraries. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15590 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs
Michael Haubenwallner added the comment: Erm, the latter should read: For Linux, with this configure variant: $ configure --prefix=/prefix --disable-shared CC=gcc CXX=g++ Now reading GNU ld manpage for Linux: $ PKG_CONFIG_PATH=/prefix/lib/pkgconfig pkg-config --libs python-3.4 new: -L/prefix/lib -lpython3.4m -Xlinker -export-dynamic ld(1), at '--export-dynamic', tells about '--dynamic-list=file' to export specific symbols only - which actually looks similar to '-bE:file' for AIX... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15590 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19521] parallel build race condition on AIX since python-3.2
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: +248 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10656] Out of tree build fails on AIX
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- title: Out of tree build fails on AIX 5.3 - Out of tree build fails on AIX versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10656] Out of tree build fails on AIX 5.3
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: -246 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10656] Out of tree build fails on AIX
Michael Haubenwallner added the comment: Basically the same as Tristan's patch, with a little improvement to not rely on PATH to find makexp_aix within ld_so_aix. Thanks! -- Added file: http://bugs.python.org/file35476/issue10656-out-of-source-build-on-aix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16189] ld_so_aix not found
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: -247 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16189 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16189] ld_so_aix not found
Michael Haubenwallner added the comment: Problem here is that LDSHARED points to $(BINLIBDEST)/config/ld_so_aix, but it should be $(LIBPL)/ld_so_aix. Although an independent problem, this diff shares context with file#35476, so this patch depends on issue #10656. -- keywords: +patch versions: +Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35478/issue16189-distutils-do-not-find-ld_so_aix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16189 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19521] parallel build race condition on AIX since python-3.2
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: -248 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19521] parallel build race condition on AIX since python-3.2
Michael Haubenwallner added the comment: Patch including configure update now. -- Added file: http://bugs.python.org/file35479/issue19521-parallel-build-race-on-aix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21660] Substitute @TOKENS@ from sysconfig variables, for python-config and python.pc
New submission from Michael Haubenwallner: On the way to fix issue#15590 especially for AIX, I've discovered that the values provided by config.status used to substitute @TOKEN@ in python-config, python.pc as well as python-config.py may contain references to Makefile variables not known within config.status. So I thought to use the sysconfig.get_config_vars() here as an additional source for replaceable tokens. This also allows to remove the hackisch @EXENAME@ sedding for python-config.py, as well as to replace the @SO@ seen in python-config.sh. -- components: Build messages: 219756 nosy: haubi priority: normal severity: normal status: open title: Substitute @TOKENS@ from sysconfig variables, for python-config and python.pc versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21660 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21660] Substitute @TOKENS@ from sysconfig variables, for python-config and python.pc
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: +249 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21660 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21660] Substitute @TOKENS@ from sysconfig variables, for python-config and python.pc
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- keywords: +patch Added file: http://bugs.python.org/file35481/6510f2df0d81.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21660 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs
Michael Haubenwallner added the comment: So this diff - depending on issue#21660 - now drops showing any $LIBS from python-config, as python-modules usually do not link against any python-known libraries. Instead, now there is a new configure variable LINKFORMODULE, which is shown by python-config --ldflags. And $LINKFORSHARED is added to python.pc (for pkg-config). Eventually, this allows to drop those Darwin hackery wrt. python-framework, as the python library isn't linked against the modules any more - but to PYTHONFRAMEWORK via LINKFORMODULE instead. However, I don't have any Darwin around here: anyone? For AIX, this looks good so far. Thanks! -- hgrepos: +250 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15590 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- keywords: +patch Added file: http://bugs.python.org/file35485/32143cda4d80.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15590 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs
Michael Haubenwallner added the comment: Well, they should not be identical, as they are for different use cases. pkg-config python is to build an application containing a python interpreter (like python$EXE): + Link against libpython.so. Additionally, + re-export symbols from libpython.so for the python-modules (platform-specific). = This is similar to build against any other library, thus using 'pkg-config python'. python-config is to build a python-module (like build/lib.platform-pyver/*.so): + No need to link against libpython.so, instead + expect symbols from libpython.so to be available at runtime, platform specific either + as a list of symbols to import from the main executable (AIX), or + as undefined symbols at build-time (Linux, others), or = This is specific to python-modules, thus using 'python-config'. -- nosy: +haubi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15590 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21272] use _sysconfigdata to itinialize distutils.sysconfig
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- nosy: +haubi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21272 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17454] ld_so_aix not used when linking c++ (scipy)
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- nosy: +haubi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17454 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: Removed file: http://bugs.python.org/file32542/python-tip-aix-absbuilddir.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
Michael Haubenwallner added the comment: issue#10656 is the out-of-source part already. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10656] Out of tree build fails on AIX 5.3
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: +246 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16189] ld_so_aix not found
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- hgrepos: +247 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16189 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10656] Out of tree build fails on AIX 5.3
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- nosy: +haubi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16189] ld_so_aix not found
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- nosy: +haubi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16189 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13493] Import error with embedded python on AIX 6.1
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- nosy: +haubi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13493 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14150] AIX, crash loading shared module into another process than python like operator.so results in 0509-130
Michael Haubenwallner added the comment:
Doing it this way strictly requires runtime-linking to be enabled, to have the
main executable and the module use the same runtime instance of the
libpython${VERSION}.so symbols.
Instead, the main executable better should re-export the python symbols
itself. This requires httpd to be linked with -bE:/path/to/python.exp linker
flag.
--
nosy: +haubi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14150
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
Michael Haubenwallner added the comment: Kindly ping. Do you prefer another report for the aix-absbuilddir patch as this one is already closed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
Michael Haubenwallner added the comment: Erm, question target was the python committers. And I'd create the new issue if they prefer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17919] AIX POLLNVAL definition causes problems
Michael Haubenwallner added the comment: This is a regression since 2.7.4 because of http://bugs.python.org/issue15989. As the 'events' and 'revents' members of 'struct pollfd' both are bitfields, the question actually is why they need to be signed at all. Additionally: I'm wondering why poll_modify() and internal_devpoll_register() haven't been updated along issue#15989, as both still have 'i' for the 'events' arg. Attached patch (for hg-tip) changes the 'events' for 'struct pollfd' to be generally treated as unsigned short bitfield. Not that I know of one, but the 0x hack may break on platforms where 'short' is not 16bits - casting to (unsigned short) instead feels more save. Additional question: Would it make sense to have the 'BHIkK' types check for overflow? Thank you! -- nosy: +haubi Added file: http://bugs.python.org/file32585/python-tip-unsigned-pollfd-events.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17919] AIX POLLNVAL definition causes problems
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19529] Fix unicode_aswidechar() with 4byte unicode and 2byte wchar_t, for AIX
Michael Haubenwallner added the comment: It is the abort() libc function being called, causing a core file to be written. And I can see the backtrace from both the core file or when running in the debugger. Yes: I already have included this fix into my python-3.2.5 packaging. I'm basically fine when this patch is accepted technically, although I'd prefer to see it included in the next 3.2 release, if any. In fact I've reported it only because I've seen a 2.7 release recently - ohw, and 2.6.9 yesterday, so I've expected there eventually may be another 3.2 release too. Yes: This bug does not exist since 3.3 any more due to the rewrite. And indeed I'd also call this a security fix because it is of the invalid memory read type: I do see the filenames being truncated after 112 characters when building in some longer build-path. Thank you! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19529 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
Michael Haubenwallner added the comment: 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? -- nosy: +haubi Added file: http://bugs.python.org/file32542/python-tip-aix-absbuilddir.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19529] Fix unicode_aswidechar() with 4byte unicode and 2byte wchar_t, for AIX
New submission from Michael Haubenwallner: The problem raises during build already when trying to run setup.py, where ./python is unavailable to locate the 'encodings' module and aborts. It turns out that (some of) the filenames searched for are broken due to wrong conversion from unicode (across wchar_t) to char. Attached patch is for 3.2 only, should be obvious enough. Thanks! -- components: Interpreter Core files: python-3.2-aix-unicode_aswidechar.patch keywords: patch messages: 202429 nosy: haubi priority: normal severity: normal status: open title: Fix unicode_aswidechar() with 4byte unicode and 2byte wchar_t, for AIX type: crash versions: Python 3.2 Added file: http://bugs.python.org/file32544/python-3.2-aix-unicode_aswidechar.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19529 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19521] parallel build race condition on AIX since python-3.2
New submission from Michael Haubenwallner: Since python-3.2, there is a race condition building in parallel on AIX: Consider these Makefile(.pre.in) rules: $(BUILDPYTHON): ... $(LINKCC) ... $(LINKFORSHARED) ... Modules/_testembed: ... $(LINKCC) ... $(LINKFORSHARED) ... Modules/_freeze_importlib: ... $(LINKCC) ... On AIX, the variables get these values: LINKCC = $(srcdir)/Modules/makexp_aix Modules/python.exp ... LINKFORSHARED = -Wl,-bE:Modules/python.exp ... Now $(BUILDPYTHON) and Modules/_testembed may run in parallel, causing Modules/python.exp to be created by two instances of makexp_aix eventually running at the same time. Attached patch fixes this problem for cpython tip (doubt supporting AIX 4.1 and earlier still is necessary). Thank you! -- components: Build files: python-tip-aix-parallel.patch keywords: patch messages: 202357 nosy: haubi priority: normal severity: normal status: open title: parallel build race condition on AIX since python-3.2 versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file32534/python-tip-aix-parallel.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19521] parallel build race condition on AIX since python-3.2
Michael Haubenwallner added the comment: I'm unsure about the real purpose of _testembed, but given the name it does make sense to me to export the same symbols as $(BUILDPYTHON), thus reusing python.exp. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue941346] AIX shared library fix
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: You can remove -L\$(srcdir) on this line, but then you need to specify the full path to Modules/python.exp. See patch below: Interesting, didn't experience this to be necessary with Python-2.7.1 here... Maybe because I do an in-source build, haven't tried an out-of-source build at all. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue941346 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11172] Avoid '.' as runpath on AIX
New submission from Michael Haubenwallner michael.haubenwall...@salomon.at: Spotted in issue#941346 msg#128214, the -L$(srcdir) should be removed from BLDSHARED on AIX: The problem is that '-L$(srcdir)' adds '$(srcdir)' to the runpath too (as there is no '-blibpath' argument), opening a security hole for libpythonX.Y.so as well as the modules.so. As LDLIBRARY points to the immediate file 'libpython$(VERSION).so' instead of '-lpython$(VERSION)', I don't see the need for '-L$(srcdir)' at all. -- components: Build files: python-2.7.1-aix-safe-runpath.patch keywords: patch messages: 128293 nosy: haubi priority: normal severity: normal status: open title: Avoid '.' as runpath on AIX type: security versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20730/python-2.7.1-aix-safe-runpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue941346] AIX shared library fix
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: Sébastien, why did you need to add '-L$(srcdir)' to BLDSHARED in these patches? As LDLIBRARY points to the immediate file 'libpython$(VERSION).so' instead of '-lpython$(VERSION)', I don't see the need for '-L$(srcdir)' at all. The problem is that '-L$(srcdir)' adds '$(srcdir)' to the runpath too (as there is no '-blibpath' argument), opening a security hole for libpythonX.Y.so as well as the modules.so. -- nosy: +haubi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue941346 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7719] distutils: ignore .nfsXXXX files
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at: -- nosy: +haubi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment:
Sébastien, while this gives expected results on the AIX box here, it still has
one subtle problem:
AC_TRY_LINK may fail due to missing declaration in sys/file.h _or_ due to
missing implementation in libc.
The subsequent AC_CHECK_LIB won't fail when the implementation is in libbsd but
the declaration is missing - this is the case on not-so-recent AIX5.3 (and the
reason python worked there before).
Another minor nit is configure's output when libbsd is needed:
checking for flock... checking for flock in -lbsd... yes
yes
Anyway - I've hacked up another variant (with recent autoconf manual at hand),
which really should cover all known situations now (additionally using
cache-checks):
AC_CACHE_CHECK([for flock declaration], [ac_cv_flock_decl],
[AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM(
[#include sys/file.h],
[void* p = flock]
)],
[ac_cv_flock_decl=yes],
[ac_cv_flock_decl=no]
)
])
if test x${ac_cv_flock_decl} = xyes; then
AC_CHECK_FUNCS(flock,,
AC_CHECK_LIB(bsd,flock,
[AC_DEFINE(HAVE_FLOCK)
AC_DEFINE(FLOCK_NEEDS_LIBBSD, 1, Define if flock needs to be linked with
bsd library.)
])
)
fi
Thank you anyway!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4026
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: While I do agree this being an AIX bug, it is not a blocker here: fcntl extension does not _depend_ on flock, it just does _prefer_ flock: If not available, fcntl extension uses something else (fcntl IIRC), as it did (even without linking libbsd) before the AIX5.3-patch, which just added flock to the headers (the implementation in libbsd already has been there before the patch). The problem after that AIX5.3-patch was that the compile-check found flock, and then fcntl extension failed to link due to missing libbsd. So it's just for how to detect flock, where the most safe variant is both the compile- and link-check. When one of them fails, flock should not be flagged as available and the alternative gets used. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: Sorry to be pedantic - but it looks like (don't have a build environment at hand at the moment) it will fail to build as 64bit on the not-so-up-to-date AIX with missing 64bit flock implementation: There, the compile-check will succeed and define HAVE_FLOCK, but the link-check will fail - which really should reset have_flock to 'no'. IMO, HAVE_FLOCK should be defined when _both_ checks succeed only, not upon the compile-check only as it is done now. Thank you! -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: Using this patch based on current py3k branch I've been able now to build the fcntl module for 32bit aix5.3 (with flock) and 64bit aix5.3 (without flock), both using an old gcc-3.3.6, as well as for 64bit linux. If necessary, I should be able to create a similar patch for the other branches tomorrow. -- Added file: http://bugs.python.org/file18787/flock-check-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: While I've not tested these patches myself, I do think there still is an unhandled case: building a 64bit python. As libbsd.a contains 32bit objects only, there is no 64bit flock(). So AC_CHECK_LIB(bsd,flock) may still fail, which should result in have_flock=no then. Thank you! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7742] please avoid 'which' in Modules/ld_so_aix
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: @Stefan: Nope, setting some PATH in ~/.cshrc is the wrong thing to do, and it actually is the reason for this issue at all: 'which' is intended to tell the location of some command that would be used when started on current commandline or within current running shell-script using _current_ PATH. When ~/.cshrc modifies PATH, the found command-path would be wrong (or not found at all). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: This very same problem happens (with Python-2.6.2) on AIX5.3 now too, after upgrading to: $ oslevel -s 5300-08-09-1013 Unlike before (comparing with old build logs), this AIX5.3 now provides flock() in sys/file.h and libbsd.a[shr.o] like AIX6.1. Interesting enough, /usr/lib/libbsd.a contains 32bit shared objects only, so -lbsd does not help in 64bit mode (don't know if python actually supports 64bit on AIX). I don't have an AIX6.1 to check this. Because of this, upgrading checking for flock from compile- to link-check (eventually trying -lbsd a second time) might help? -- nosy: +haubi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: Ohw, looking on another machine, being AIX5.3 TL6: $ oslevel -s 5300-06-00- Here flock() is provided in libbsd.a(shr.o) (32bit only) too, but it isn't declared in any header-file. So that recent AIX5.3 patchset just adds the flock() declaration, not the function itself (is already there). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7742] please avoid 'which' in Modules/ld_so_aix
New submission from Michael Haubenwallner michael.haubenwall...@salomon.at: In Modules/ld_so_aix there is `which $CC` to search for the full compiler's path. Unfortunately, /usr/bin/which on AIX is a csh-script and thus ~/.cshrc gets sourced before doing the path search. Now, when the user does set some PATH in ~/.cshrc, `which` might print a wrong path for the compiler, causing the build to fail (at best). It would be better to do the path search without launching an external program. -- files: ld_so_aix-which.patch keywords: patch messages: 98070 nosy: haubi severity: normal status: open title: please avoid 'which' in Modules/ld_so_aix versions: Python 3.2 Added file: http://bugs.python.org/file15955/ld_so_aix-which.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7742] please avoid 'which' in Modules/ld_so_aix
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: Uhm, as I read the patch again, there's room for improvement of pywhich(): it likely fails with CC=/full/path/to/cc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6163] [HP-UX] ld: Unrecognized argument: +s -Ldir
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: compiler.find(gcc) = 0 or compiler.find(g++) = 0 Why not `(gcc in compiler or g++ in compiler)`? Just curious. Fine with me too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6163 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6163] [HP-UX] ld: Unrecognized argument: +s -Ldir
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment:
Basically yes, two minor ones:
*) also look for 'g++',
*) string.find() returns the index where found, -1 when not found,
so:
{{{
...
elif sys.platform[:5] == hp-ux:
if compiler.find('gcc') = 0 or compiler.find('g++') = 0:
return [-Wl,+s, -L + dir]
return [+s, -L + dir]
...
}}}
Two lines below already is another search for 'gcc' or 'g++', which also
should be changed from 'compiler[:3]' to 'compiler.find()':
{{{
...
elif compiler.find(gcc) = 0 or compiler.find(g++) = 0:
return -Wl,-R + dir
...
}}}
Thank you!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6163
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6163] [HP-UX] ld: Unrecognized argument: +s -Ldir
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: But compiler[:3] implies that the compiler string starts *with* 'gcc'. so are you sure we're looking for 'gcc' anywhere in the string, or at the beginning of it ? It is very common to use the host triplet in the compiler name, like 'i686-pc-linux-gnu-gcc', even for non-cross builds. Sometimes the compiler string also looks like 'ccache gcc' or 'distcc gcc'. Even '/path/to/some/gcc' is possible, in combination with '/path/to/ccache' and/or '/path/to/distcc'. And sometimes the version number is appended, like 'gcc-X.Y.Z'. Also ABI-specific flags might be set there, like 'gcc -m32'. In any case, I find these string searches very weak in there. Agreed, but AFAICT, native and other non-gcc compilers never do have something like 'gcc' in their installation path, especially not in their executable basename (on AIX, HP-UX, Solaris). So eventually it is save enough to search for gcc/g++ after the last path-separator, although this won't work for things like 'gcc -I/my/local/include'. I am going to refactor a function in distutils that guesses the type of compiler, given a list of known compilers 'names' and a list of matching strings (or regular expressions) for them. The most reliable way IMHO would be to preprocess '#ifdef __GNUC__', and avoid searching the compiler string for anything. Thank you! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6163 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6163] [HP-UX] ld: Unrecognized argument: +s -Ldir
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment:
Ohw, indeed, this line was copied from 3 lines below, sorry!
The actual patch I'm using does not do { compiler[:3] == 'gcc' }, but {
compiler.find(gcc) }, to also work when CC=gcc-version, but this is a
different problem independent of hp-ux.
But exactly, his should be 'if', being gcc on hp-ux.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6163
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6163] [HP-UX] ld: Unrecognized argument: +s -Ldir
Michael Haubenwallner michael.haubenwall...@salomon.at added the comment: While at it: gcc does not understand '+s', it does need '-Wl,+s'. -- nosy: +haubi Added file: http://bugs.python.org/file14514/distutils_hpux_libdir_option-gcc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6163 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6308] termios fix for QNX breaks HP-UX
New submission from Michael Haubenwallner michael.haubenwall...@salomon.at: The patch for issue 175 in Include/pyport.h to include sys/termio.h before termios.h for QNX does break for HP-UX: On HP-UX, 'struct termios' gets declared within sys/termio.h, but when included via termios.h _only_. Due to the include guard, it does not declare 'struct termios' when included via termios.h the second time. This is Python-2.6.2, but the code looks unchanged in trunk. As I'm not sure how best to fix this, for 2.6.2 here I go with: -#ifdef HAVE_SYS_TERMIO_H +#if defined(HAVE_SYS_TERMIO_H) defined(__QNX__) Thanks! -- components: Build messages: 89507 nosy: haubi severity: normal status: open title: termios fix for QNX breaks HP-UX type: compile error versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
