[issue44789] Code compliance concern in Parser/pegen/pegen.c
New submission from Dennis Clarke : With release 3.9.6 I see failures in compile on three system architectures and with three compilers. I did check with GCC 10.2.1 ( Debian 10.2.1-6 ) on IBM Power and also with FreeBSD UNIX LLVM/Clang 12.0.1 on AMD64 and also with Oracle Studio C99 strict in Solaris UNIX on Fujitsu SPARC64 wherein we see a consistent fail within the source : Parser/pegen/pegen.c This is due to a standards compliance failure as per section 6.10.3 Macro replacement. Please see constraints item 4. This fails to compile on Solaris 10 UNIX, FreeBSD 14.0 AMD64 and on Debian Linux. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional -- components: C API messages: 398612 nosy: blastwave priority: normal severity: normal status: open title: Code compliance concern in Parser/pegen/pegen.c type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44789] Code compliance concern in Parser/pegen/pegen.c
Dennis Clarke added the comment:
Let me see if I can be a bit more clear with the problem that I am
seeing on three separate systems. It does seem to be an issue in
a macro :
1) Debian Linux on IBM Power ppc64 big-endian :
enceladus$ uname -a
Linux enceladus 5.13.4-genunix #1 SMP Tue Jul 20 12:42:08 EDT 2021 ppc64
GNU/Linux
enceladus$ gcc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
enceladus$
enceladus$
enceladus$ ls Parser/pegen/pegen.c Parser/pegen/pegen.h
Parser/pegen/pegen.c Parser/pegen/pegen.h
enceladus$
enceladus$ /usr/bin/gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG \
> -fwrapv -Wall -std=iso9899:1999 -pedantic -g -O0 -fno-builtin -m64 \
> -mno-quad-memory-atomic -mfull-toc -mno-multiple -mupdate -mbig \
> -mregnames -fno-unsafe-math-optimizations -pedantic-errors \
> -Wextra -Wno-unused-result -Wno-unused-parameter \
> -Wno-missing-field-initializers \
> -Werror=implicit-function-declaration \
> -fvisibility=hidden \
> -I./Include/internal -I. -I./Include \
> -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE \
> -DPy_BUILD_CORE -o Parser/pegen/pegen.o Parser/pegen/pegen.c
In file included from Parser/pegen/pegen.c:5:
Parser/pegen/pegen.h: In function ‘_RAISE_SYNTAX_ERROR_INVALID_TARGET’:
Parser/pegen/pegen.h:297:47: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
297 | return RAISE_SYNTAX_ERROR("invalid syntax");
| ^
Parser/pegen/pegen.c: In function ‘_PyPegen_check_barry_as_flufl’:
Parser/pegen/pegen.c:71:74: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
71 | RAISE_SYNTAX_ERROR("with Barry as BDFL, use '<>' instead of
'!='");
|
^
Parser/pegen/pegen.c: In function ‘tokenizer_error’:
Parser/pegen/pegen.c:323:81: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
323 | RAISE_SYNTAX_ERROR("EOF while scanning triple-quoted string
literal");
|
^
Parser/pegen/pegen.c:326:67: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
326 | RAISE_SYNTAX_ERROR("EOL while scanning string literal");
| ^
Parser/pegen/pegen.c:329:62: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
329 | RAISE_SYNTAX_ERROR("unexpected EOF while parsing");
| ^
Parser/pegen/pegen.c:332:90: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
332 | RAISE_INDENTATION_ERROR("unindent does not match any outer
indentation level");
|
^
Parser/pegen/pegen.c: In function ‘_PyPegen_number_token’:
Parser/pegen/pegen.c:953:62: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
953 | "in Python 3.6 and greater");
| ^
Parser/pegen/pegen.c: In function ‘_PyPegen_run_parser’:
Parser/pegen/pegen.c:1132:73: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
1132 | RAISE_SYNTAX_ERROR("error at start before reading any
input");
|
^
Parser/pegen/pegen.c:1135:62: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
1135 | RAISE_SYNTAX_ERROR("unexpected EOF while parsing");
| ^
Parser/pegen/pegen.c:1139:60: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
1139 | RAISE_INDENTATION_ERROR("unexpected indent");
|^
Parser/pegen/pegen.c:1142:62: error: ISO C99 requires at least one argument for
the "..." in a variadic macro
1142 | RAISE_INDENTATION_ERROR("unexpected unindent");
| ^
Parser/pegen/pegen.c:1145:52: error: ISO C99 requires at least one argument for
the "..." in a vari
[issue44789] Code compliance concern in Parser/pegen/pegen.c
Dennis Clarke added the comment: This was an excellent opportunity to review these CFLAGS and to ponder the value of each. This took me a day to write and was then reviewed by a team. I hope it answers your question. --- There is nothing too unusual in the CFLAGS on any system. I have used this sort of config for many years without too many problems. There are always some open source software packages that are a bit "special" and one can not expect strictly portable code everywhere. However some packages are really critical and Python would be one of those certainly. We have to agree that the usage of some gnu extensions breaks "-pedantic" always. Let us go over these compiler flags for a Solaris 10 SPARC64 system. beta $ echo $CC /opt/developerstudio12.6/bin/c99 Clearly that is the C99 compiler. Similar to running f77 in order to handle Fortran77 code. However the f77 is just a symlink these days and it points to f90. Such is life in the modern world. CFLAGS ? I guess we can go over these one by one however they are all clearly documented in the "Oracle(R) Developer Studio 12.6: C User's Guide" which we may see here : https://docs.oracle.com/cd/E77782_01/html/E77788/index.html There is a fairly extensive discussion regarding "Features of C 99" : https://docs.oracle.com/cd/E77782_01/html/E77788/bjayy.html OKay lets look at these flags that I have used almost everywhere for many years : -Xc is seen in section B.2.84 : (c = conformance) Issues errors and warnings for programs that use non-ISO C constructs. This option is strictly conformant ISO C without K&R C compatibility extensions. As a side comment here the compiler in use is C99 and this option is somewhat similar to saying "-pedantic" and yes I really do mean iso9899:1999 without any special flavour sauce added :) The documentation states : See D.1 for a discussion of supported 1999 ISO/IEC features. See Appendix H for a discussion of differences between ISO/IEC C and K&R C. All of that discussion is in the links above. -errtags=yes -errwarn=%none -errfmt=error -erroff=%none -errshort=full Lets look at these as a group of options that ensure we get a really verbose error message when needed. From section B.2.12 we see -errfmt[=[no%]error] which is used if you want to prefix the string "error:" to the beginning of error messages so they are more easily distinguishable from warning messages. The prefix is also attached to warnings that are converted to errors by -errwarn. Section B.2.17 we see -errwarn[=t] where I use t=%none such that "... any warning message from causing the compiler to exit with a fatal status should any warning message be issued." Around the same section we see -errtags=a for a being either a yes or no. From the manual "Displays the message tag for each warning message of the C compiler that can be suppressed with the -erroff option or made a fatal error with the -errwarn option." This brings us to the -erroff flag discussed in section B.2.14 where it simply says %none enables all warning messages. Finally there is -errshort which will determine how much data we get from an error message. The option "full" should be pretty clear and the section B.2.15 states "Error messages are printed with tag names for types which have tag names. If there is no tag name, the type is shown in expanded form." -m64 -xarch=sparc These are trivial and merely specify that we are building for a 64 bit platform and the target architecture is a SPARC. In this specific case we are using a Fujitsu SPARC64 based server where the full cpu description would be SPARC64-VII+ clock 2860 MHz. -xO0 -g -xs The -xO0 option is similar to what we see from GCC and LLVM/Clang and other compilers. The compiler optimization level where here we use a zero and this is not documented. It is in fact the default and the compiler accepts this flag just fine. Any other number from 1 upwards to 5 indicates a level of optimization that is ever more complex. To be blunt the use of a debugging switch -g with any level of optimization above 2 will result in limited debug data. Section B.2.150 lays out everything one would want to know for the SPARC and AMD64 platforms. The -xs option is a bit special in that it allows debug information to be encoded into the executable binaries. Section B.2.172 shows us the default is in fact -x
[issue44789] Code compliance concern in Parser/pegen/pegen.c
Dennis Clarke added the comment: Minor note. I am going to change the component to the Parser. -- components: +Parser -C API ___ Python tracker <https://bugs.python.org/issue44789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44789] CPython cannot be compiled with -pedantic
Dennis Clarke added the comment: I very likely do not understand what is happening here. From my little perspective the Python project has become far too critical to be yet another language that can not be ported and used just about anywhere. I often port software from various places into strange machines and even onto z/OS mainframe type places. There is nothing more beautiful than to take some C89 clean code and watch it just work. Flawlessly. Even the OpenSSL project is locked neatly to that old C89 standard. I have tried to get into a discussion about C99 but was always flatly told that we need OpenSSL to work everywhere. Pretty much on anything that you can get a compiler will do just fine. With the exception of some very small embedded devices or tight memory constraints. It just works. Sadly the Go Programming language is not like that. Neither is Rust. When I look at The Python Project "Style Guide for C Code" here : https://www.python.org/dev/peps/pep-0007/ The message is clearly stated : Python versions greater than or equal to 3.6 use C89 with several select C99 features: - Standard integer types in and . We require the fixed width integer types. - static inline functions - designated initializers (especially nice for type declarations) - intermingled declarations - booleans - C++-style line comments Future C99 features may be added to this list in the future depending on compiler support (mostly significantly MSVC). Don't use GCC extensions (e.g. don't write multi-line strings without trailing backslashes). All function declarations and definitions must use full prototypes (i.e. specify the types of all arguments). Only use C++ style // one-line comments in Python 3.6 or later. No compiler warnings with major compilers (gcc, VC++, a few others). That last line is a bit of a dream but I didn't write that. I merely took a copy from the "Style Guide for C Code". So perhaps that needs a rewrite and just state that the code will be mostly C99 safe and maybe it would be best to just say iso9899:2011 and keep on plowing forwards. One thing is certain, I built the OpenSSL 3.0.0 beta1 software on a pile of systems in the last few weeks and then rebuilt a pile of dependant libs and tools. They all work. Curl and libCurl is flawless. I am trying to get Apache httpd 2.4.x ( and also trunk ) built and running. The only major piece missing, critical and really important, is Python. OKay I also have issues with ISC Bind but they seem to be drinking some strange brew lately and their unit tests and other code has gone crab sideways. That is another problem in someone elses backyard. Python however looks to be very highly portable and it just works on everything. Pretty much. So having said all that should this just be iso9899:2011 with no major surprises? ps: from the "Style Guide for C Code" we also see these gems : Use 4-space indents and no tabs at all. No line should be longer than 79 characters. If this and the previous rule together don't give you enough room to code, your code is too complicated -- consider using subroutines. No line should end in whitespace. If you think you need significant trailing whitespace, think again -- somebody's editor might delete it as a matter of routine. Those are just priceless old rules from the Fortan punchcard days. -- ___ Python tracker <https://bugs.python.org/issue44789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44789] CPython cannot be compiled with -pedantic
Dennis Clarke added the comment: Oh, I think we can give up on -pedantic and -pedantic-errors. It is just a nifty litmus paper test to see how code cranks under nasty contraints. I would be hapyp with iso9899:1999 or even iso9899:2011. Thank you for the feedback and the excellent response time. I am so very happy with the Python team bug report process and quite frankly there are a lot of good people working on the quality code. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional -- ___ Python tracker <https://bugs.python.org/issue44789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39708] final link stage in compile fails for 3.8.1 with missing CFLAGS
New submission from Dennis Clarke : During compile after a sucessful configure the final link stage fails : /opt/developerstudio12.6/bin/cc -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib-o python Programs/python.o -Wl,-R,/usr/local/lib -L. -lpython3.8d -lsocket -lnsl -lintl -lrt -ldl -lsendfile -lm -lm ld: fatal: file /opt/developerstudio12.6/lib/compilers/crti.o: wrong ELF class: ELFCLASS32 ld: fatal: file processing errors. No output written to python gmake: *** [Makefile:578: python] Error 2 real 107.96 user 100.96 sys 21.96 alpha$ Easily done manually : alpha$ $CC $CFLAGS -R/usr/local/lib -L/usr/local/lib \ > -o python Programs/python.o \ > -Wl,-R,/usr/local/lib -L. -lpython3.8d -lsocket -lnsl -lintl -lrt -ldl > -lsendfile -lm alpha$ alpha$ file python python: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped alpha$ -- components: Build messages: 362405 nosy: blastwave priority: normal severity: normal status: open title: final link stage in compile fails for 3.8.1 with missing CFLAGS type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39709] missing CFLAGS during make tests results in test and compile failure
New submission from Dennis Clarke : Seems to be an error in the Makefile(s) in that the "make test" can not compile some code for the correct architecture : The process seems to begin well and fine : alpha$ LD_LIBRARY_PATH=`pwd` /usr/local/bin/gmake test 2>&1 | tee ../python_3.8.1_SunOS5.10_sparc64vii+.003.test.log LD_LIBRARY_PATH=/usr/local/build/python_3.8.1_SunOS5.10_sparc64vii+.003 ./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 /opt/developerstudio12.6/bin/cc -c -xcode=pic32 -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib -D_REENTRANT -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib-I../Python-3.8.1/Include/internal -IObjects -IInclude -IPython -I. -I../Python-3.8.1/Include -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=600 -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=600 -xcode=pic32 -DPy_BUILD_CORE -o Modules/_math.o ../Python-3.8.1/Modules/_math.c cc: Warning: multiple use of -Q option, previous one discarded. LD_LIBRARY_PATH=/usr/local/build/python_3.8.1_SunOS5.10_sparc64vii+.003 CC='/opt/developerstudio12.6/bin/cc' LDSHARED='/opt/developerstudio12.6/bin/cc -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib -G -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib ' OPT='' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ../Python-3.8.1/setup.py build running build running build_ext building '_struct' extension creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local/build creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local/build/Python-3.8.1 creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local/build/Python-3.8.1/Modules . . . /opt/developerstudio12.6/bin/cc -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib -G -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=600 build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local/build/Python-3.8.1/Modules/_uuidmodule.o -L. -L/usr/local/lib -R/usr/local/lib -luuid -o build/lib.solaris-2.10-sun4u.64bit-3.8-pydebug/_uuid.so cc: Warning: multiple use of -Q option, previous one discarded. *** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.10-sun4u.64bit-3.8-pydebug/_curses.so: symbol acs32map: referenced symbol not found *** WARNING: renaming "_curses_panel" since importing it failed: No module named '_curses' INFO: Could not locate ffi libs and/or headers Python build finished successfully! The necessary bits to build these optional modules were not found: _gdbm ossaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. The following modules found by detect_modules() in setup.py, have been built by the Makefile instead, as configured by the Setup files: _abc atexitpwd time Failed to build these modules: _ctypes Following modules built successfully but were removed because they could not be imported: _curses _curses_panel
[issue39711] SIGBUS and core dumped during tests of 3.8.1
New submission from Dennis Clarke : The testsuite fails badly with a SIGBUS thus : . . . 0:01:37 load avg: 2.81 [ 26/423/1] test_frozen passed 0:01:40 load avg: 2.77 [ 27/423/1] test_eof passed -- running: test_importlib (31.7 sec), test_socket (31.2 sec) 0:01:41 load avg: 2.75 [ 28/423/1] test_poplib passed -- running: test_importlib (32.8 sec), test_socket (32.2 sec) 0:01:45 load avg: 2.71 [ 29/423/1] test_aifc passed -- running: test_importlib (37.2 sec), test_socket (36.7 sec) 0:01:46 load avg: 2.71 [ 30/423/1] test_unicode_file_functions passed -- running: test_importlib (37.8 sec), test_socket (37.2 sec) 0:01:51 load avg: 2.71 [ 31/423/1] test_listcomps passed -- running: test_importlib (42.9 sec), test_socket (42.4 sec) 0:01:54 load avg: 2.75 [ 32/423/1] test_asdl_parser passed -- running: test_importlib (46.0 sec), test_socket (45.4 sec) 0:01:57 load avg: 2.77 [ 33/423/1] test_richcmp passed -- running: test_importlib (49.1 sec), test_socket (48.6 sec) 0:02:01 load avg: 2.78 [ 34/423/1] test_importlib passed (48.3 sec) -- running: test_socket (51.8 sec) 0:02:04 load avg: 2.76 [ 35/423/1] test_rlcompleter passed -- running: test_socket (55.6 sec) 0:02:08 load avg: 2.75 [ 36/423/1] test_sys_setprofile passed -- running: test_socket (59.0 sec) 0:02:16 load avg: 2.72 [ 37/423/1] test_tuple passed -- running: test_socket (1 min 7 sec), test_capi (31.0 sec) 0:02:39 load avg: 2.73 [ 38/423/1] test_c_locale_coercion passed -- running: test_ast (31.4 sec), test_socket (1 min 30 sec), test_capi (53.8 sec) 0:02:44 load avg: 2.76 [ 39/423/1] test_symtable passed -- running: test_ast (36.6 sec), test_socket (1 min 35 sec), test_capi (58.9 sec) 0:03:01 load avg: 2.88 [ 40/423/1] test_ast passed (51.2 sec) -- running: test_socket (1 min 52 sec), test_capi (1 min 15 sec) 0:03:04 load avg: 2.89 [ 41/423/1] test_pow passed -- running: test_socket (1 min 55 sec), test_capi (1 min 18 sec) 0:03:19 load avg: 2.90 [ 42/423/1] test_http_cookiejar passed -- running: test_socket (2 min 10 sec), test_capi (1 min 33 sec) 0:03:21 load avg: 2.88 [ 43/423/1] test_defaultdict passed -- running: test_socket (2 min 12 sec), test_capi (1 min 36 sec) 0:03:24 load avg: 2.86 [ 44/423/1] test_winconsoleio skipped -- running: test_socket (2 min 15 sec), test_capi (1 min 38 sec) test_winconsoleio skipped -- test only relevant on win32 0:03:34 load avg: 2.77 [ 45/423/1] test_cprofile passed -- running: test_socket (2 min 25 sec), test_capi (1 min 48 sec) 0:03:37 load avg: 2.75 [ 46/423/1] test_nntplib passed -- running: test_socket (2 min 28 sec), test_capi (1 min 51 sec) 0:03:42 load avg: 2.74 [ 47/423/1] test_xml_dom_minicompat passed -- running: test_socket (2 min 33 sec), test_capi (1 min 56 sec) 0:03:46 load avg: 2.77 [ 48/423/1] test_pkgimport passed -- running: test_socket (2 min 37 sec), test_capi (2 min) 0:04:00 load avg: 2.80 [ 49/423/1] test_timeout passed -- running: test_socket (2 min 51 sec), test_capi (2 min 14 sec) 0:04:04 load avg: 2.78 [ 50/423/1] test_pkg passed -- running: test_socket (2 min 54 sec), test_capi (2 min 18 sec) 0:04:09 load avg: 2.79 [ 51/423/1] test_mimetypes passed -- running: test_support (34.9 sec), test_socket (2 min 59 sec), test_capi (2 min 23 sec) 0:04:18 load avg: 2.85 [ 52/423/1] test_base64 passed -- running: test_support (44.1 sec), test_socket (3 min 9 sec), test_capi (2 min 32 sec) 0:04:23 load avg: 2.88 [ 53/423/1] test_metaclass passed -- running: test_support (48.9 sec), test_socket (3 min 13 sec), test_capi (2 min 37 sec) 0:04:24 load avg: 2.89 [ 54/423/2] test_timeit crashed (Exit code 1) -- running: test_support (50.4 sec), test_socket (3 min 15 sec), test_capi (2 min 38 sec) Traceback (most recent call last): File "/usr/local/build/Python-3.8.1/Lib/runpy.py", line 193, in _run_module_as_main File "/usr/local/build/Python-3.8.1/Lib/runpy.py", line 86, in _run_code File "/usr/local/build/Python-3.8.1/Lib/test/regrtest.py", line 14, in File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/__init__.py", line 1, in File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/cmdline.py", line 4, in File "/usr/local/build/Python-3.8.1/Lib/test/support/__init__.py", line 6, in File "/usr/local/build/Python-3.8.1/Lib/asyncio/__init__.py", line 8, in File "/usr/local/build/Python-3.8.1/Lib/asyncio/base_events.py", line 45, in File "/usr/local/build/Python-3.8.1/Lib/asyncio/staggered.py", line 10, in File "", line 991, in _find_and_load File "", line 975, in _find_and_load_unlocked File "", line 671, in _load_unlocked File "", line 779, in exec_module File "", line 874, in get_code File "", line 972, in get_data MemoryError Warning -- regrtest worker thread failed: Traceback (most recent call last): File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest_
[issue29269] test_socket failing in solaris
Dennis Clarke added the comment: Well here we are in 2020 and Solaris systems are still running just fine. In fact, some big Fujitsu SPARC systems are running in production for years and years and also, no surprise, this test still fails horrifically on old stable Solaris 10. Python is turning into a piece of supposedly open source software with many commercial interests with their hands inside of it. I am not sure how to get this bug fixed but I can certainly report that it is still broken in 3.7.8 on a very stable and reliable platform. -- nosy: +blastwave versions: +Python 3.7 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue29269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42358] Python 3.9.0 unable to detect ax_cv_c_float_words_bigendian value on nigendan system
New submission from Dennis Clarke : Seems related to issue42173 where the idea on the table was, simply to drop Solaris support and to quote Mr Stinner to "let the code slowly die". Regardless of this sort of neglect there are people who do try to use Python on big endian risc systems such as Solaris or Debian Linux in fact. Wherein a trivial configure reveals : alpha$ ../Python-3.9.0/configure --prefix=/opt/bw \ > --enable-shared --disable-optimizations \ > --enable-loadable-sqlite-extensions \ > --enable-ipv6 --with-pydebug --without-dtrace \ > --with-openssl=/opt/bw --with-ssl-default-suites=openssl \ > --without-gcc configure: WARNING: unrecognized options: --without-gcc checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for python3.9... no checking for python3... python3 checking for --enable-universalsdk... no checking for --with-universal-archs... no checking MACHDEP... "sunos5" checking for gcc... /opt/developerstudio12.6/bin/cc -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib checking whether the C compiler works... yes . . . checking for __fpu_control... no checking for __fpu_control in -lieee... no checking for --with-libm=STRING... default LIBM="-lm" checking for --with-libc=STRING... default LIBC="" checking for x64 gcc inline assembler... no checking whether float word ordering is bigendian... unknown configure: error: Unknown float word ordering. You need to manually preset ax_cv_c_float_words_bigendian=no (or yes) according to your system. So it seems that the m4/ax_c_float_words_bigendian.m4 needs to be manually hacked or the configure script itself is at fault. I will give this a try on big endian IBM Power and also IBM Power9 ppc64le as well as FreeBSD running in RISC-V rv64imafdc little endian and see what happens. I suspect that the little endian systems will be no great concern as the bulk of Python devs seem to have never seen anything else other than little endian systems running Red Hat. To hack around this floating point endian test with blunt force : alpha$ alpha$ diff -u configure.orig configure --- configure.orig Mon Oct 5 15:07:58 2020 +++ configure Sat Nov 14 19:37:13 2020 @@ -14425,7 +14425,7 @@ else -ax_cv_c_float_words_bigendian=unknown +ax_cv_c_float_words_bigendian=yes cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ @@ -14442,9 +14442,9 @@ fi if $GREP seesnoon conftest.$ac_objext >/dev/null ; then if test "$ax_cv_c_float_words_bigendian" = unknown; then -ax_cv_c_float_words_bigendian=no +ax_cv_c_float_words_bigendian=yes else -ax_cv_c_float_words_bigendian=unknown +ax_cv_c_float_words_bigendian=yes fi fi alpha$ alpha$ diff -u m4/ax_c_float_words_bigendian.m4.orig m4/ax_c_float_words_bigendian.m4 --- m4/ax_c_float_words_bigendian.m4.orig Mon Oct 5 15:07:58 2020 +++ m4/ax_c_float_words_bigendian.m4Sat Nov 14 19:35:44 2020 @@ -42,7 +42,7 @@ [AC_CACHE_CHECK(whether float word ordering is bigendian, ax_cv_c_float_words_bigendian, [ -ax_cv_c_float_words_bigendian=unknown +ax_cv_c_float_words_bigendian=yes AC_COMPILE_IFELSE([AC_LANG_SOURCE([[ double d = 9090423496703681033747047890550501147621169273561563201479712084405348886581669527372346909785805625751702019124748742951693213050356065000232756451757077848023672452514052012137173920149654013264010999420565776568942592.0; @@ -54,9 +54,9 @@ fi if $GREP seesnoon conftest.$ac_objext >/dev/null ; then if test "$ax_cv_c_float_words_bigendian" = unknown; then -ax_cv_c_float_words_bigendian=no +ax_cv_c_float_words_bigendian=yes else -ax_cv_c_float_words_bigendian=unknown +ax_cv_c_float_words_bigendian=yes fi fi alpha$ This is a hack of course and it gets past the endian test sickness. Shortly thereafter the compile fails due to a trivial C99 code problem : /opt/developerstudio12.6/bin/cc -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib -c -O -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib -D_REENTRANT -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemal
[issue42358] Python 3.9.0 unable to detect ax_cv_c_float_words_bigendian value on nigendan system
Dennis Clarke added the comment: I gave up on trying to compile this code with C99. Trying C11 and hope that blows up in different places. -- ___ Python tracker <https://bugs.python.org/issue42358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42358] Python 3.9.0 unable to detect ax_cv_c_float_words_bigendian value on nigendan system
Dennis Clarke added the comment: I see : https://github.com/python/cpython/blob/master/Objects/exceptions.c#L2316 the void return has been fixed and really I should not be looked anywhere else other than the master sources on some oddball platform. I will start over. -- ___ Python tracker <https://bugs.python.org/issue42358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue23459] Linux: expose the new execveat() syscall
On 05/30/2016 06:12 PM, Марк Коренберг wrote: Марк Коренберг added the comment: It is actual to me due to it's AT_EMPTY_PATH feature (I download script, verify signature, and want to run it) See also `man 3 fexecve` Why not to add `dir_fd=None` ? (as in `os.rmdir()` for example). It should be very small patch, as I think. This system call only exists in some recent versions of Linux : #include int execveat(int dirfd, const char *pathname, char *const argv[], char *const envp[], int flags); Using code that depends on it will break portability. Dennis Clarke ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS
New submission from Dennis Clarke:
While compiling from sources I see in the process :
.
.
.
creating build/temp.solaris-2.10-sun4v.64bit-3.5/libffi
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking target system type... sparc-sun-solaris2.10
checking for gsed... /usr/local/bin/gsed
checking for a BSD-compatible install...
/usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/Modules/_ctypes/libffi/install-sh
-c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p...
/usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/Modules/_ctypes/libffi/install-sh
-c -d
checking for gawk... /usr/local/bin/gawk
checking whether /usr/local/bin/gmake sets $(MAKE)... yes
checking whether /usr/local/bin/gmake supports nested variables... yes
checking for gcc... /opt/solarisstudio12.4/bin/cc
checking whether the C compiler works... no
configure: error: in
`/usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/build/temp.solaris-2.10-sun4v.64bit-3.5/libffi':
configure: error: C compiler cannot create executables
See `config.log' for more details
The reason for this error is that the build process down in the libffi
directory seems to spawn its own "configure" stage wherein the CFLAGS are lost,
forgotten or simply not used and therefore a trivial compile fails because of :
configure:3873: /opt/solarisstudio12.4/bin/cc -I/usr/local/include
-I/usr/local/ssl/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS
-D_LARGEFILE64_SOURCE conftest.c >&5
ld: fatal: file /opt/solarisstudio12.4/lib/compilers/crti.o: wrong ELF class:
ELFCLASS32
ld: fatal: file processing errors. No output written to a.out
configure:3877: $? = 2
configure:3915: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libffi"
| #define PACKAGE_TARNAME "libffi"
| #define PACKAGE_VERSION "3.1"
| #define PACKAGE_STRING "libffi 3.1"
| #define PACKAGE_BUGREPORT "http://github.com/atgreen/libffi/issues";
| #define PACKAGE_URL ""
| #define PACKAGE "libffi"
| #define VERSION "3.1"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3920: error: in
`/usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/build/temp.solaris-2.10-sun4v.64bit-3.5/libffi':
configure:3922: error: C compiler cannot create executables
See `config.log' for more details
The configure process MUST use the CFLAGS that were passed to the original
configure stage and reside in the Makefile. The absence of the flag -m64
causes a 32-bit compile here and thus the compile fails.
--
components: Build
messages: 266458
nosy: blastwave
priority: normal
severity: normal
status: open
title: python 3.5.1 will not compile because libffi module uses wrong CFLAGS
type: compile error
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue27133>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS
Dennis Clarke added the comment: On 05/26/2016 06:01 PM, Zachary Ware wrote: > > Zachary Ware added the comment: > > Would you be interested in submitting a patch? Sure, of course. There are a number of problems in the Makefile(s) for a system not using gcc and where CFLAGS and LD_foo is pretty important. Certainly where the RPATH and RUNPATH in the resultant ELF output binaries really really matters. So yes, sure. If I can get it sorted out. > The whole ctypes package and the bundled libffi in particular are > fairly unloved. Put me in that ground also :-\ > As a workaround, if you have libffi installed on your system I try to avoid it actually. > you can use the '--with-system-ffi' flag to Python's configure > script to direct the ctypes build to use the installed libffi. If there were such a thing as system libffi then I would give that a try but for now I am on my own and will need to everything from sources. > Also note that unless you specifically need ctypes (or are > building for someone who might) Well, strictly speaking, I don't. However someone else may and I have to roll this out to a pile of systems eventually. For now it is just internal on my build servers. > it may not be the end of the world for ctypes to not be available; Is there a configure option to disable them? I should look. > the overall build should not fail just due to a ctypes build failure. cool ... let's hope for the best. Dennis -- ___ Python tracker <http://bugs.python.org/issue27133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS
Dennis Clarke added the comment: On 05/26/2016 06:01 PM, Zachary Ware wrote: > > Zachary Ware added the comment: > > Would you be interested in submitting a patch? Right now I am trying to get a clean build of libffi outside of the python tree and then will use the --use-system-libffi option to get around this mess. Of course, that sort of means that the libffi sources build and test clean and that, of course, is its own struggle. see https://sourceware.org/ml/libffi-discuss/2016/msg00024.html and https://sourceware.org/ml/libffi-discuss/2016/msg00025.html I'll keep you posted on progress here. Dennis -- ___ Python tracker <http://bugs.python.org/issue27133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
