Change by Michael Haubenwallner :
--
pull_requests: +13592
pull_request: https://github.com/python/cpython/pull/737
___
Python tracker
<https://bugs.python.org/issue36
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 l
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
Changes by Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>:
--
pull_requests: +652
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>:
--
pull_requests: +560
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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 (spec
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 (
Changes by Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>:
--
nosy: +haubi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>:
--
nosy: +haubi
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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/i
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 BLDSHAR
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: +251
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19521
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: +252
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10656
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: +253
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16189
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
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
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
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
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: +248
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19521
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
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: -246
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10656
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
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: -247
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16189
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
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: -248
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19521
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
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
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: +249
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21660
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
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
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
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
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
nosy: +haubi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21272
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
nosy: +haubi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17454
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
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
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: +246
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10656
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
hgrepos: +247
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16189
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
nosy: +haubi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10656
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
nosy: +haubi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16189
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
nosy: +haubi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13493
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
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
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
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
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
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
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
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
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
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
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
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
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
Changes by Michael Haubenwallner michael.haubenwall...@salomon.at:
--
nosy: +haubi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7719
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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_
72 matches
Mail list logo