Michael Felt added the comment:
The good news! Your patch, better rewrite, of _aix_platform.py is working!
Many thanks!
--
___
Python tracker
<https://bugs.python.org/issue39
Michael Felt added the comment:
Fantastic! Many thanks!
--
___
Python tracker
<https://bugs.python.org/issue39936>
___
___
Python-bugs-list mailing list
Unsub
Michael Felt added the comment:
I'll take a look as well.
On 17/03/2020 16:14, STINNER Victor wrote:
> STINNER Victor added the comment:
>
>> New changeset 0bcbfa43d55d9558cdcb256d8998366281322080 by Tal Einat (Michael
>> Felt) in branch 'master':
&
Michael Felt added the comment:
I may be mistaken, but I do not think the change introduced a regression.
While it is true that this case would not have appeared if there was
still a count of the field-separators an IPv6 address with 5 ':' and 17
characters would have failed as
Michael Felt added the comment:
On 18/03/2020 13:55, STINNER Victor wrote:
> STINNER Victor added the comment:
>
>> I may be mistaken, but I do not think the change introduced a regression.
I meant - I had never considered IPv6 in the Address column, just as I
suspect, whoev
Michael Felt added the comment:
@BTaskaya - can you elaborate on what issues you ran into? Perhaps open an
issue on the repository I started to work on getting this improved.
Thanks!
--
___
Python tracker
<https://bugs.python.org/issue39
Michael Felt added the comment:
the XLC compiler has an option to create "listing" files. The content depends
on the arguments passed to the xlc compilers.
>From memory (as I always need to look them up) these include -qinfo and
>-qsource (plus arguments)
FYI: besides show
Michael Felt added the comment:
My apologies for the late reply -
Here is 3.6.10:
Python 3.6.10 (default, Mar 24 2020, 14:12:31) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> tim
New submission from Michael Felt :
This is a regression in v3.6.10 and v3.7.6
`make install` creates a symbolic link `python3` that points to the executable
python3.X
In versions v3.6.10 and v3.7.6 the executable is created as python3.Xm while
the symbolic link still points to python3.X
Michael Felt added the comment:
I tried looking at the blurbs to get an idea of what might have been the change
- but nothing to indicate a change to the install process in any of "next" NEWS
blurbs that are currently in branch 3.7
NEWS.d/next/Build/README.rst
NEWS.d/next/C API/
Change by Michael Felt :
--
versions: +Python 3.5
___
Python tracker
<https://bugs.python.org/issue40073>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Felt added the comment:
I see that it is also incorrect for v3.5.9
What is surprising - is that the logic is okay for python-config ->
python-config3.X -> python-config-3.Xm
root@x065:[/data/prj/python/python3-3.5.9/X32]ls -l opt/bin
total 8728
lrwxrwxrwx 1 root
Michael Felt added the comment:
Back again - I understood a lot less then, maybe more now..
iirc, get_platform() asin sysconfig.get_platform() and
distutils.util.get_platform() are suppposed to return a suitable PEP425 tag
that identifies the ABI of the running interpreter - eg.g, 32-bit
Michael Felt added the comment:
FYI: IMHO it is artifact of the way an xlc compiler is setup. Maybe this is a
new default (I see they changed the names of config files).
On my server (with xlc v11) I do not get them, but on a different server (with
xlc v13) I do get .lst files.
So, seems
New submission from Michael Felt :
The is a check if compiler is xlc, and skips a test if it is.
XLC no longer installs in /usr/vac, and the test_search_cpp fails (again)
--
components: Distutils
messages: 365302
nosy: Michael.Felt, dstufft, eric.araujo
priority: normal
severity
Change by Michael Felt :
--
keywords: +patch
pull_requests: +18587
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19225
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
With PR19263 The AIX bots are now red.
==
ERROR: test_input_no_stdout_fileno (test.test_builtin.PtyTests)
--
Traceback (most
Michael Felt added the comment:
Ah - great. Sorry for the noise then.
--
___
Python tracker
<https://bugs.python.org/issue31160>
___
___
Python-bugs-list mailin
Michael Felt added the comment:
I think something is not yet what it needs to be:
the bots both finish test with:
test_zip_pickle (test.test_builtin.BuiltinTest) ... ok
Timeout (0:15:00)!
Thread 0x0001 (most recent call first):
File
"/home/buildbot/buildarea/3.x.aixtools-aix-p
New submission from Michael Felt :
related to
Two AIX bots - different environments - continue to fail the test:
`test_builtin` since
During the first run - the test fails with something such as:
0:31:47 [215/420] test_abc passed -- running: test_builtin (14 min 10 sec)
0:32:17 running
Michael Felt added the comment:
did not get issue numbers in above: issue31160 and issue40094.
I waited a day, before posting - in the hope it would go away.
Also, I have been testing manually (no -j arguments) - and test_builtin passes
when run manually. So, becoming hard to dissect and
Michael Felt added the comment:
Now consistently - stalled.
aixtools@x064:[/home/aixtools/py39-3.9]git diff
diff --git a/Lib/test/test_builtin.py b/Lib/test/test_builtin.py
index eaada1b504..89c4ebc2bd 100644
--- a/Lib/test/test_builtin.py
+++ b/Lib/test/test_builtin.py
@@ -1849,26 +1849,40
Michael Felt added the comment:
If I move the close to before the support.waitprocess() call I get:
aixtools@x064:[/home/aixtools/py39-3.9]./python -m test test_builtin
0:00:00 Run tests sequentially
0:00:00 [1/1] test_builtin
I am child - this is my PID:2254
I am parent:21954666 with
Michael Felt added the comment:
I tried moving the child/parent logic blocks and get this as debug output:
aixtools@x064:[/home/aixtools/py39-3.9]./python -m test test_builtin
0:00:00 Run tests sequentially
0:00:00 [1/1] test_builtin
I am child - this is my PID:8519822
I am parent:6422696
Michael Felt added the comment:
Next debug info:
I am child - this is my PID:8519830
I am parent:18284612 with child:8519830fd:6 input:b'quux\r'
I am parent:18284612 with lines:[]
I am child - exiting PID:8519830
I am parent:18284612 with lines:['stdin.isatty(): True']
Michael Felt added the comment:
FYI: in child block:
calling os.exit(0), rather than os._exit() gives same result.
--
___
Python tracker
<https://bugs.python.org/issue40
Michael Felt added the comment:
To get it to move forward: as it is not solely and AIX thing (see bpo-40-140)
This works: but is it what is wanted?
Tests result: SUCCESS
aixtools@x064:[/home/aixtools/py39-3.9]git diff
diff --git a/Lib/test/test_builtin.py b/Lib/test/test_builtin.py
index
Change by Michael Felt :
--
pull_requests: +18670
pull_request: https://github.com/python/cpython/pull/19308
___
Python tracker
<https://bugs.python.org/issue31
Change by Michael Felt :
--
keywords: +patch
pull_requests: +18671
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19308
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
Thanks for the fix!
--
___
Python tracker
<https://bugs.python.org/issue40155>
___
___
Python-bugs-list mailing list
Unsub
Michael Felt added the comment:
Just manually verified that PR19377, when compiled against xlc - crashes during
make:
rm -f libpython3.9d.a
ar rcs libpython3.9d.a Modules/getbuildinfo.o Parser/acceler.o
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o
Michael Felt added the comment:
Just checked - seems to be SPECIFIC to xlc-v16 as neither xlv-v11 nor xlc-v13
have any issues building.
--
___
Python tracker
<https://bugs.python.org/issue40
Michael Felt added the comment:
requesting backport of PR19225.
After switching my bot to xlc-v13 it fails this test.
See botstatus mail excerpt:
The Buildbot has detected a failed build on builder POWER6 AIX 3.8 while
building python/cpython.
Full details are available at:
https
Michael Felt added the comment:
Yes, looks like I need to find that. thx for the reminder.
--
___
Python tracker
<https://bugs.python.org/issue37009>
___
___
New submission from Michael Felt :
Calling this a compile error - as it seems to be compiler dependent.
In other projects - when I have experienced issues as this it has been an
uninitiated variable - somewhere.
I would appreciate some suggestions on how to best debug this - as it seems to
Michael Felt added the comment:
dbx output:
Again: help appreciated.
(dbx) run -X tracemalloc
Objects/genobject.c:127: _PyObject_GC_TRACK: Assertion "!(((PyGC_Head
*)(op)-1)->_gc_next != 0)" failed: object already tracked by the garbage
collector
Enable tracemalloc to get the
Michael Felt added the comment:
After git bisect - comes down to:
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[0003c2dc1d4cf5b122e73e83177fd274fa9a9913] bpo-40096: Support
__attribute__((__noreturn__)) on xlc (GH-19204
Michael Felt added the comment:
It is only XLC-v16 that fails. XLC-v11 and XLC-v13 work fine. Am digging to see
which version (< v16, or >= v16) is not working as expected.
--
___
Python tracker
<https://bugs.python.org/i
Michael Felt added the comment:
On 10/04/2020 14:01, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> The assertion failure occurs in _PyObject_GC_TRACK() at:
>
> static void
> gen_dealloc(PyGenObject *gen)
> {
> PyObject *self = (PyObject *) gen;
>
Michael Felt added the comment:
Thank you!
On 09/04/2020 17:33, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> I backported the fix to 3.8 to fix AIX 3.8 buildbots.
>
> --
>
> ___
> Python tracker
&g
Michael Felt added the comment:
After my build I have the following:
$ ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS'
Objects/genobject.c:127: _PyObject_GC_TRACK: Assertion "!(((PyGC_Head
*)(op)-1)->_gc_next != 0)" failed: object already tracked by the g
Michael Felt added the comment:
With the print statements - it does not crash:
./python -E -S -m sysconfig --generate-posix-vars ; if test $?
-ne 0 ; then echo "generate-posix-vars failed" ; rm -f
./pybuilddir.txt ; exit 1 ; fi
Objects/genobject.c:122:537318120
Objects/g
Michael Felt added the comment:
Also tried this:
./python -E -S -m sysconfig --generate-posix-vars ; if test $?
-ne 0 ; then echo "generate-posix-vars failed" ; rm -f
./pybuilddir.txt ; exit 1 ; fi
Objects/genobject.c:127: _PyObject_GC_TRACK: Assertion "!(((PyG
Michael Felt added the comment:
On 14/04/2020 14:54, Batuhan Taskaya wrote:
> Batuhan Taskaya added the comment:
>
>> With the print statements - it does not crash:
> I think this isn't directly relevant with prints but about re-compiling?
> (just guessing).
I onl
Michael Felt added the comment:
On 14/04/2020 19:28, Michael Felt wrote:
> Michael Felt added the comment:
>
> On 14/04/2020 14:54, Batuhan Taskaya wrote:
>> Batuhan Taskaya added the comment:
>>
>>> With the print statements - it does not crash:
>> I thi
Michael Felt added the comment:
Do I need to open a new issue?
This breaks building _ssl on AIX.
building '_ssl' extension
xlc_r -O -I./Include/internal -I/opt/aixtools/include -I./Include -I.
-I/home/aixtools/python/cpython-master/Include
-I/home/aixtools/python/cpython-master
Michael Felt added the comment:
Also checking with gcc: get the following messages:
Failed to build these modules:
_ssl
Could not build the ssl module!
Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with
X509_VERIFY_PARAM_set1_host().
LibreSSL 2.6.4 and earlier do not provide the
Michael Felt added the comment:
And when I use a standard OpenSSL library (on AIX):
building '_ssl' extension
gcc -pthread -Wno-unused-result -Wsign-compare -g -Og -Wall -std=c99 -Wextra
-Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers
-Werror=implici
Michael Felt added the comment:
I did update, and saw that there was one more patch applied.
I think that fixed the define issues, but there may be a new concern. Ran out
of time to document it today.
Will post tomorrow.
Sent from my iPhone
> On 15 Apr 2020, at 17:53, SilentGhost wr
Michael Felt added the comment:
Checked with latest version - and working as expected. Sorry for the noise.
On 15/04/2020 17:53, SilentGhost wrote:
> SilentGhost added the comment:
>
> Michael, could you try with the latest fix in 584a3cfda4?
>
> --
>
Michael Felt added the comment:
When I have more time I hope to investigate specifically what is
different in the assembly code - with/without the __noreturn__ change.
On 19/04/2020 08:20, Batuhan Taskaya wrote:
> Batuhan Taskaya added the comment:
>
> Moving asser
New submission from Michael Felt :
As part, I assume, of PR19503, that includes 91 changed files with 27,058
additions and 147 deletions the AIX buildbot is broken.
Rather than looking/finding Modules/ld_so_aix (where I expect it to be) tests
are failing, ulitmately because they look/expect
Michael Felt added the comment:
New issue with test during PR19764:
0:03:29 [416/423/1] test_peg_generator failed (2 min 34 sec) -- running:
test_pathlib (3 min 19 sec), test_bufio (3 min 17 sec), test_concurrent_futures
(3 min 10 sec), test_multiprocessing_fork (3 min), test_subprocess (2
Michael Felt added the comment:
Currently build using xlc-v13 hangs during creation of _json.so. Trying xlc-v11.
--
___
Python tracker
<https://bugs.python.org/issue40
Michael Felt added the comment:
with the xlc-v11 environment yet another issue:
Stop.
/usr/bin/make returned an error
root@x065:[/data/prj/python/python-3.9]make V=1
xlc_r -c -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -O
-I../git/python-3.9/Include/internal -IObjects
Michael Felt added the comment:
More `make test` output:
1 test failed:
test_peg_generator
18 tests skipped:
test_devpoll test_epoll test_gdb test_ioctl test_kqueue
test_msilib test_ossaudiodev test_spwd test_startfile test_tix
test_tk test_ttk_guionly test_unicode_file
Michael Felt added the comment:
Thanks for the quick work. I’ll test with xlc as well, as the builds behave
differently this afternoon.
Sent from my iPhone
> On 23 Apr 2020, at 16:31, Pablo Galindo Salgado
> wrote:
>
>
> Pablo Galindo Salgado added the comment:
>
Michael Felt added the comment:
Thanks for the quick response. I see both bots are good.
--
___
Python tracker
<https://bugs.python.org/issue40370>
___
___
Pytho
New submission from Michael Felt :
Currently, on AIX, whenever the -j option is passed to make there are many
WARNINGS from the loader (ld) re: duplicate symbols.
While it is not possible to eliminate these warnings completely - as some are
not related to the Python build, but external (3rd
Change by Michael Felt :
--
keywords: +patch
pull_requests: +19081
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19759
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
Bot failed for AIX https://buildbot.python.org/all/#builders/227/builds/978
with:
0:07:11 Re-running test_asyncio in verbose mode
Failed to import test module: test.test_asyncio.test_events
Traceback (most recent call last):
File
"/home/shager/cp
Michael Felt added the comment:
I could not "fathom" the buildbot test results - however, a manual build of
PR29170 on 3.9 works: I'll try 3.8, but then from master (assuming it is
already part of master) -- and that works as well.
Thanks for t
Michael Felt added the comment:
On Windows - in distutils (?) did they perhaps make a change only for windows,
for whatever reason.
I don't have a python3.7 pr a 3.8 handy atm.
Not sure what 'distutils' pip updates either - but with py36 and pip 20.2.4 and
setuptools 40.6.2
Michael Felt added the comment:
Looking at https://github.com/python/cpython/pull/22088/files
imho: the patch forced Windows behavior ("""Initialize the module as
appropriate for NT""") to be equivalent to vars['SO'] - which is what the test
used t
Michael Felt added the comment:
Sorry Victor - family matters - so I was not watching for several days.
--
___
Python tracker
<https://bugs.python.org/issue41
New submission from Michael Felt :
While working on a PR for issue42323 I get an error with the generated
./configure even without my patch.
Working from commit 37a6d5f8027f969418fe53d0a73a21003a8e370d
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]git log --oneline | head
37a6d5f
Michael Felt added the comment:
This is what I find via bisect:
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]git checkout . && git
bisect bad
c6d7e82d19c091af698d4e4b3623648e259843e3 is the first bad commit
commit c6d7e82d19c091af698d4e4b3623648e259843e3
Author: Petr Viktor
Michael Felt added the comment:
This is beginning to look like it is an issue with the version of automake
installed:
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]automake --version
Unescaped left brace in regex is deprecated, passed through in regex; marked by
<-- HERE i
Michael Felt added the comment:
The 'issue' is that a package known as autoconf-archive must ALSO be installed
- so that aclocal has a definition for ax_check_compile_flag.
Guessing that resolution is `third_party` - If not, please explain what the
resolution flag i
Michael Felt added the comment:
I have been doing a lot of research on this. Wish I had thought do start the
way I finished.
Basically, when math.nextafter() was added all the AIX bots were on systems
running AIX earlier than AIX 7.2 TL2.
When AIX 7.2 TL2 was released (roughly Q3 2017) a
Michael Felt added the comment:
While my patch in working - was successful in what it attempted to do, it did
not fix this test issue.
Instead - I reinstalled the `bos.adt.libm-7.2.0.0` fileset, to backout of the
so-called bugfix/APAR IV95512.
@David - can you take this up with AIX support
Michael Felt added the comment:
OK - looking at this again.
This looks very similiar to another 'coredump' issue (will have to look for the
number later). iirc, when something called 'pgen', or similiar was modified.
Here is a lengthy `dbx` dump.
If I am reading t
New submission from Michael Felt :
issue40192 introduced the use of nanosecond reporting of time.
The new routine called is not available in AIX 5.3:
xlc_r -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -O
-I../git/python-3.9/Include/internal -IObjects -IInclude -IPython -I.
-I
Michael Felt added the comment:
I think this is showing up again. Ot seemed to be away when using xlcv13 (and
is away with xlcv11).
I switched my bot off of xlc (v13) because compile fails again - and I'll
investigate manually using xlc again.
If you could prep a PR where the chan
Michael Felt added the comment:
The 'fancy' file name breaks on latin-1 character set.
aixtools@gcc119:[/home/aixtools/python/py39-3.9]
a4fa9a95153a3800dea60b3029b2dcaf8a4f6acb Lib/test/test_importlib/test_main.py
<
diff --git a/Lib/test/test_importlib/test_m
Michael Felt added the comment:
Actually, iirc - xlc is c99 plus a few extra settings.
The configuration files for xlc are, traditionally, in /etc (the later
versions of the compiler have moved them into /opt/show/where so that
multiple versions of the compiler can be installed.
buildbot@x064
Michael Felt added the comment:
No, it is not supported - asin there are no new patches - but there are
organizations that use it.
imho - those organizations are not likely to be using the latest Python
- but I have been packaging Python on AIX 5.3 and AIX 6.1 - as these
packages run
Michael Felt added the comment:
specifically, makexp_aix - from 1998-1999 - did not consider parallelization.
make -j2 is sufficient to create the following issue - that frequently leads to
a failed compile/build.
./Modules/makexp_aix Modules/python.exp . libpython3.9d.a; gcc -pthread
Change by Michael Felt :
--
title: AIX: parallel build and ld WARNINGS -> AIX: makexp_aix, parallel build
(failures) and ld WARNINGS
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
Yes, it is less hacky - and something to pursue later - as a better
solution. Even the idea of perhaps no longer needing makexp_aix and/or
ld_so_aix and python.exp is much better solution.
However, the goal of this PR is to have something now - that removes the
Michael Felt added the comment:
I'll switch my bot https://buildbot.python.org/all/#/builders/119 to use
c99_r rather than xlc_r.
Test 1129 will b e the first with c99_r (and xlc v13).
On 11/06/2020 00:37, Stefan Krah wrote:
> Stefan Krah added the comment:
>
> So it
Michael Felt added the comment:
I’ll switch back to xlc ( even try without the _r ) and look for the macro asap
(vacation and occasional travel).
Sent from my iPhone
> On 15 Jun 2020, at 21:20, Stefan Krah wrote:
>
>
> Stefan Krah added the comment:
>
> Thanks!
>
Michael Felt added the comment:
I switched the "aixtools" bot back to "xlc", and also back to my POWER6
server that runs xlc-v11.
iirc it is xlc-v13 (or maybe even v12) that is having trouble with
_decimal (or is it POWER8). From memory, _decimal was compiling properly
wit
Michael Felt added the comment:
There is still a lot of AIX 6.1 out there, and iirc, there may be
"extended" support available.
However, at this point in time the bots run (most of the time) on AIX
7.2, -- occasionally, on AIX 7.1. And when I (personally) test - it is
usually on AI
Michael Felt added the comment:
I have been doing manual tests - and it seems build is broken for AIX
and xlc.
I shall be working on a git bisect to try and identify what broke it for
xlc-v11. Finding what broke xlc-v13 will require more time.
Note: it is no longer limited to _decimal not
New submission from Michael Felt :
As the bots were both running - based on gcc - this was not noticed immediately.
issue40334 implements PEP 617, the new PEG parser for CPython.
Using bisect I located:
commit c5fc15685202cda73f7c3f5c6f299b0945f58508 (HEAD, refs/bisect/bad)
Author: Pablo
Michael Felt added the comment:
Well, the first step -s just showing where the segmentation fault occurs (in
pegen.c).
I am not really 'wiser' in what I should be looking at. I'll try adding a
fprintf(stderr, ) to see if I can figure out a bit more.
For the expert
Michael Felt added the comment:
OK - merely added some fprintf statements.
When it is working as expected, the k->type values seem to be between 500 and
535 - when it fails the k->type value is frequently 9 digits (e.g., 537120904)
- and it seems to never become -1 -- which would e
Michael Felt added the comment:
Thanks Kevin.
I took your patch (added your name to blurb as well).
Only difference was to remove Qsystem (or something), from the pathnames.
--
versions: +Python 3.7
___
Python tracker
<https://bugs.python.
Michael Felt added the comment:
Iirc, my debug shows that k is not NULL, as k++ is not going to suddenly become
smaller. And my debug shows it grows by a constant.
My gut says the pointer to the base of the tokens is wrong, because the key
types are such different values. Or do you know
Michael Felt added the comment:
My apologies for lack of context.
On 05/07/2020 20:27, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado added the comment:
>
> Unfortunately, I am having a hard time parsing your error description because
> is not immediate to distinguish:
&
Michael Felt added the comment:
Thanks for getting back to this. ++1 :)
On 25/06/2020 11:49, Serhiy Storchaka wrote:
> Serhiy Storchaka added the comment:
>
> test_bdb fails on non-UTF-8 locale because Python executes a Python code from
> the corresponding "encodings"
Michael Felt added the comment:
Glad you figured it out!
I doubt I would have. Thx!!
On 06/07/2020 14:37, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado added the comment:
>
> This is enough to reproduce the problem:
>
> #include
>
> typedef struct {
> c
Michael Felt added the comment:
On 06/07/2020 16:35, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado added the comment:
>
>> Glad you figured it out!
> Well, this is not over ;)
>
> We should confirm that this is either a bug in XLC or a violation of C99
probably a
Michael Felt added the comment:
I tried check.c and check_bad.c using xlc-v11 (on my POWER6) - and the
results were the same as in Pablo's entry.
On the gcc119 host - using the v13 compiler, check_bad does not crash.
Not gotten to testing xlc-v16 yet.
I have seen lots of options
Michael Felt added the comment:
Note: - two different systems, different HW, different OS levels.
xlc-v11, master : commit deb016224cc506503fb05e821a60158c83918ed4 (HEAD
-> master, upstream/master, upstream/HEAD)
Segmentation fault in _PyEval_EvalFrameDefault at line 941 in file
"../
Michael Felt added the comment:
I also tested xlC v16, and then it just hung, for hours - while all of you were
being more productive.
I’ll kickoff my bot again, and see how it goes.
Sent from my iPhone
> On 6 Jul 2020, at 21:31, miss-islington wrote:
>
>
> miss-islingto
Michael Felt added the comment:
I saw the mails last night and restarted my bot - it still fails.
Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
know asap.
Yes - expecting 3.8 and 3.7 to build, but want to be sure.
On 06/07/2020 23:34, Pablo Galindo Salgado wrote
Michael Felt added the comment:
On 07/07/2020 11:12, Michael Felt wrote:
> Michael Felt added the comment:
>
> I saw the mails last night and restarted my bot - it still fails.
> Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
3.7, 3.8 and 3.9 built, mas
Michael Felt added the comment:
Here is the stack trace - still during initialization: And in "ceval.c,
but dbx does not like how the 'h files are being used: line 941 and 659
lines don't match :(
(dbx) list
"object.h" has only 659 lines
Segmentation fault in _PyEval
101 - 200 of 737 matches
Mail list logo
