reproduce-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[task #16051] Python build bug with curses.h in commit 775fc03


From: Boud Roukema
Subject: [task #16051] Python build bug with curses.h in commit 775fc03
Date: Sun, 3 Oct 2021 16:21:47 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

URL:
  <https://savannah.nongnu.org/task/?16051>

                 Summary: Python build bug with curses.h in commit 775fc03
                 Project: Maneage
            Submitted by: boud
            Submitted on: Sun 03 Oct 2021 08:21:46 PM UTC
         Should Start On: Sun 03 Oct 2021 12:00:00 AM UTC
   Should be Finished on: Sun 03 Oct 2021 12:00:00 AM UTC
                Category: Software
                Priority: 3 - Low
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00

    _______________________________________________________

Details:

BUG: Maneage commit 775fc03 has fatal errors compiling some python modules. A
second round of './project configure' leads to the Maneage system considering
all packages to be compiled correctly, despite the errors declared as fatal.
It is not known if the fatal errors cause problems when running python.


SYSTEM DETAILS:
* Debian GNU/Linux bullseye 11.0, i.e stable, x86_64 architecture
* Maneage commit 775fc03


LOG:
https://cosmo.torun.pl/~boud/log.20211003.1.775fc03.python.bug.bz2


EXTRACTS from the log:

This is a parallel compile, so the specific commands might be interleaved.
[Using the '--debug' option doesn't seem to work fully in parallel, giving
some lines printed in an interleaved way - probably some output is buffered
and not rapidly synced.]

There are a few sections such as the following:


/BUILD/software/installed/bin/gcc -pthread -fPIC -Wno-unused-result
-Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra
-Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers
-Werror=implicit-function-declaration -I./Include/internal -I./Include -I.
-I/BUILD/software/installed/include -I/usr/local/include
-I/BUILD/software/build-tmp/Python-3.8.5/Include
-I/BUILD/software/build-tmp/Python-3.8.5 -c
/BUILD/software/build-tmp/Python-3.8.5/Modules/_blake2/blake2module.c -o
build/temp.linux-x86_64-3.8/BUILD/software/build-tmp/Python-3.8.5/Modules/_blake2/blake2module.o
/BUILD/software/installed/bin/gcc -pthread -fPIC -Wno-unused-result
-Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra
-Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers
-Werror=implicit-function-declaration -I./Include/internal -I./Include -I.
-I/BUILD/software/installed/include -I/usr/local/include
-I/BUILD/software/build-tmp/Python-3.8.5/Include
-I/BUILD/software/build-tmp/Python-3.8.5 -c
/BUILD/software/build-tmp/Python-3.8.5/Modules/grpmodule.c -o
build/temp.linux-x86_64-3.8/BUILD/software/build-tmp/Python-3.8.5/Modules/grpmodule.o
In file included from
/BUILD/software/build-tmp/Python-3.8.5/Modules/_curses_panel.c:15:
./Include/py_curses.h:36:10: fatal error: curses.h: No such file or directory
   36 | #include <curses.h>
      |          ^~~~~~~~~~
compilation terminated.
In file included from
/BUILD/software/build-tmp/Python-3.8.5/Modules/_cursesmodule.c:113:
./Include/py_curses.h:36:10: fatal error: curses.h: No such file or directory
   36 | #include <curses.h>
      |          ^~~~~~~~~~
compilation terminated.
building '_elementtree' extension


The python management system itself seems to consider the build successful:


Python build finished successfully!
The necessary bits to build these optional modules were not found:
_dbm                  _gdbm                 _sqlite3           
_tkinter                                                       
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                  atexit                pwd                
time                                                           


Failed to build these modules:
_curses               _curses_panel                            


Following modules built successfully but were removed because they could not
be imported:
_uuid                 nis                                      

running build_scripts
creating build/scripts-3.8


Nevertheless, the first '.project configure' run fails. A second iteration of
'./project configure' runs without further interruption.

PRESENCE of curses.h:

All these are present:


.local/include/ncurses/cursesapp.h  
.local/include/ncurses/cursesf.h  
.local/include/ncurses/curses.h  
.local/include/ncurses/cursesm.h  
.local/include/ncurses/cursesp.h  
.local/include/ncurses/cursesw.h  
.local/include/ncurses/ncurses_dll.h  
.local/include/ncurses/ncurses.h -> curses.h
.local/include/ncursesw/cursesapp.h  
.local/include/ncursesw/cursesf.h  
.local/include/ncursesw/curses.h  
.local/include/ncursesw/cursesm.h  
.local/include/ncursesw/cursesp.h  
.local/include/ncursesw/cursesw.h  
.local/include/ncursesw/ncurses_dll.h  
.local/include/ncursesw/ncurses.h -> curses.h
.local/include/python3.8/py_curses.h  


and the compilation path appears to be valid for finding 'curses.h', so the
bug is puzzling.


STATUS as a bug:

So far I'm not aware of this having consequences in running python scripts.
However, since we clearly have 'curses' installed as part of the _basic.mk_
system, in principle it should be easy to solve the bug of not finding
'curses.h'.

Moreover, the build *should* compile in a single run, without needing a second
_configure_ round.

However, I've rated this as "3 = low" on the priority scale, since practical
problems following from the bug are not (yet) known.

I see that the commented URL for python in 'reproduce/software/conf/urls.conf'
is http://akhlaghi.org/src . This leads to a related issue: for URLs that have
akhlaghi.org URLs alone, it would be better to include an example of the
upstream URL as a comment just before/after, and any differences should be
described. Even if the upstream URL risks being volatile and disappearing, in
many cases these will survive in the long term so making the user's task
easier would be better.





    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/task/?16051>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]