bugGNU Zile (Zile is Lossy Emacs) - Bugs: bug #58880, Solaris 11.3 and error: unknown...

 
 

bug #58880: Solaris 11.3 and error: unknown type name 'SGTTY'

Submitter:  Jeffrey Walton <noloader>
Submitted:  Sun 02 Aug 2020 07:29:59 PM UTC
   
 
Category:  None Severity:  3 - Normal
Status:  Fixed Assigned to:  None
Open/Closed:  Closed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 27 Sep 2020 04:08:12 PM UTC, comment #16: 

Closing, hoping the fix works!

Reuben Thomas <rrt>
Group administrator
Tue 01 Sep 2020 08:23:00 PM UTC, comment #15: 

Ping? It would be good to know if I've fixed the bug for you, so I can make a release if so.

By the way, one comment that I thought merited a reply; you wrote:

> How you make the leap to the bug does [not] apply to…your software is baffling.


I read the diffs between the versions shipped with Zile and the current gnulib versions and concluded that the changes were not material to this problem. (As indeed they seem not to be, as the bug was in Zile all along.)

Reuben Thomas <rrt>
Group administrator
Sun 09 Aug 2020 05:23:07 PM UTC, comment #14: 

I've pushed a commit which #includes term.h from a path matching the #include of [n]curses[w].h. Please can you see if that fixes the bug for you?

Reuben Thomas <rrt>
Group administrator
Sun 09 Aug 2020 05:18:55 PM UTC, comment #13: 

Belay my last comment. In fact, term.h is needed for tigetstr. So I think a different fix will be needed. I will attempt it shortly.

Reuben Thomas <rrt>
Group administrator
Sun 09 Aug 2020 05:14:26 PM UTC, comment #12: 

I've found a moment to look into this in more detail, and I think the problem is that the included `term.h` does not necessarily match the included `curses.h`. However, I don't think that `term_curses.c` actually needs `term.h` (certainly it doesn't on my system). Please could you try removing the line

#include <term.h>

and seeing if that fixes your problem?

Reuben Thomas <rrt>
Group administrator
Mon 03 Aug 2020 06:34:44 PM UTC, comment #11: 

If you'd like to maintain Zile, you'd be welcome to have a go!

I'm not sure about "crap polluting the landscape": Zile still has users, so I maintain it for them.

> The Gnulib folks have already corrected bugs in the software you are using. The same applies to the Autoconf Archives.


Great, do you have references? I'm quite happy to admit I could have overlooked something!

> Your configure program is broken. It does not configure Zile properly when using Ncurses.


I use Zile with ncurses, as do most of the downstream packagers I interact with, and I've had no other problems reported in many years. From the build logs you've given so far I can't tell whether there's a bug in ax_with_curses.m4 or not; perhaps you could construct a M(non-)WE and send it to the autoconf-archive maintainers?

Reuben Thomas <rrt>
Group administrator
Mon 03 Aug 2020 06:24:07 PM UTC, comment #10: 


> I'm happy to do this if there's a bug that is fixed by an update, but I've seen no evidence of one.


I don't think your judgement is on-beam.

The Gnulib folks have already corrected bugs in the software you are using. The same applies to the Autoconf Archives.

How you make the leap to the bug does apply to the software your software is baffling.

> I see no concrete evidence of a bug here, and certainly no evidence of a fix in gnulib or autoconf-archive.


This bug report is the bug. Your configure program is broken. It does not configure Zile properly when using Ncurses.

> I consider Zile to be in maintenance mode. I do not recommend it use ...


Swell. More GNU crap polluting the software landscape.

Thanks for the heads up.

Jeffrey Walton <noloader>
Mon 03 Aug 2020 06:17:28 PM UTC, comment #9: 


> But the current version is serial 18


As I said, I already looked at the differences and can see nothing significant. You're welcome to try building with the newer version and seeing if that fixes your problem. Otherwise, I'd look into your curses installation. Your patch is ncurses-specific, but Zile does not require ncurses, and should work with any POSIX-compliant curses.

> I really think Zile needs to update Gnulib and update its m4 macros. And then provide a new release.


I'm happy to do this if there's a bug that is fixed by an update, but I've seen no evidence of one.

> Zile cannot possible do the uptime marathon thing. Zile depends on Gnulib with rolling releases and the Autoconf Archive. When Zile depends on others like Gnulib it is incumbent upon Zile to pickup their bug fixes and then release a new package.


Absolutely, I'm happy to do that when there's a bug-fix. I see no concrete evidence of a bug here, and certainly no evidence of a fix in gnulib or autoconf-archive.

More generally, I consider Zile to be in maintenance mode. I do not recommend it use, I will not be adding features; I only fix bugs. Any new release risks introducing new bugs, so I'm certainly not in favour of making a new release with updated gnulib etc. just because time has passed.

Reuben Thomas <rrt>
Group administrator
Mon 03 Aug 2020 03:59:08 PM UTC, comment #8: 

Looking at m4/ax_with_curses:

$ grep serial m4/ax_with_curses.m4
#serial 13

But the current version is serial 18 at http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_with_curses.m4.

I really think Zile needs to update Gnulib and update its m4 macros. And then provide a new release.

Zile cannot possible do the uptime marathon thing. Zile depends on Gnulib with rolling releases and the Autoconf Archive. When Zile depends on others like Gnulib it is incumbent upon Zile to pickup their bug fixes and then release a new package.

Jeffrey Walton <noloader>
Mon 03 Aug 2020 03:15:45 PM UTC, comment #7: 

So I had to add another patch to Zile to get it to build as expected (https://github.com/noloader/Build-Scripts/commit/2ad78d067e05):

echo "patching source files..."
if true; then
    file="src/term_curses.c"
    cp -p "$file" "$file.fixed"
    sed 's/<term.h>/"ncurses\/term.h"/g' "$file" > "$file.fixed"
    mv "$file.fixed" "$file"
fi

<term.h> was wrong, and it caused Zile to use system's term.h. I needed "ncurses/term.h" because configure.ac did not pickup the path to the header.

Jeffrey Walton <noloader>
Mon 03 Aug 2020 02:37:37 PM UTC, comment #6: 

I think AX_WITH_CURSES is likely the problem. This is from configure.ac:

dnl Curses
AX_WITH_CURSES
if test "$ax_cv_curses" != "yes"; then
  AC_MSG_ERROR([cannot find curses])
fi
AC_ARG_VAR(CURSES_LIB, [linker flags for curses library])

I don't see where CURSES_CFLAGS is being used to pick up the location of include Ncurses header files.

---------

I also noticed another problem with the handling of Ncurses on Linux. I never reported this problem, but it seems related.

My build script for Zile (https://github.com/noloader/Build-Scripts/blob/master/build-zile.sh) has to perform the following to fix a linker error:

echo "patching Makefiles..."
IFS="" find "$PWD" -name 'Makefile' -print | while read -r file
do
    cp -p "$file" "$file.fixed"
    sed 's|-lncurses|-lncurses -ltinfo|g' "$file" > "$file.fixed"
    mv "$file.fixed" "$file"
done

I should not need the hack above because ncurses.pc says to use both -lncurses -ltinfo:

$ cat ~/tmp/ok2delete/lib/pkgconfig/ncurses.pc
# pkg-config file generated by gen-pkgconfig
# vile:makemode

prefix=/export/home/jwalton/tmp/ok2delete
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include/ncurses
abi_version=6
major_version=6
version=6.1.20180127

Name: ncurses
Description: ncurses 6.1 library
Version: ${version}
URL: https://invisible-island.net/ncurses
Requires.private:
Libs: -L${libdir} -lncurses -ltinfo
Libs.private: -ldl -lpthread
Cflags:  -D_XOPEN_SOURCE=500 -I${prefix}/include -I${includedir}

Jeffrey Walton <noloader>
Mon 03 Aug 2020 02:21:26 PM UTC, comment #5: 


> Do you know which *.pc file is expected to provide the package config info for the termcap gear?


One thing I noticed when adding an Autotools front-end to BLAKE2 (https://github.com/BLAKE2/BLAKE2/pull/64/files) during testing...

The existing pkg.m4 on many systems is not as reliable as one hopes. I found distributing the latest pkg.m4 improved the situation.

Maybe you can supply the latest pkg.m4 from the Freedesktop folks? The latest pkg.m4 is 0.29.1. You don't need the entire package - just the latest pkg.m4.

The latest can be fetched with:

    wget -O pkg.m4 https://raw.githubusercontent.com/pkgconf/pkgconf/master/pkg.m4

(This assumes pkg.m4 is the reason the include directory is not being picked up).

Jeffrey Walton <noloader>
Mon 03 Aug 2020 02:03:53 PM UTC, comment #4: 

comment #3:

> So it looks like ncurses' term.h is being overlooked in favour of /usr/include/term.h. This is a matter of providing the correct include file paths. I believe Zile is using the correct POSIX-mandated paths. (On my GNU/Linux system, /usr/include/term.h is provided by curses.)


Ugh, I'm not sure what Posix says about things.

> The other thing that could be wrong is the curses detection (m4/ax_with_curses.m4): maybe it's detecting ncurses's curses.h, but not setting the include paths so that ncurses's term.h is used? ax_with_curses.m4 has been updated since the version included with Zile, but I can't see any changes in this area.


I think the ax_* m4 macros are usually the best choice. (Or I have more faith in them than the existing stuff shipped with Autotools).

Do you know which *.pc file is expected to provide the package config info for the termcap gear?

$ ls ~/tmp/ok2delete/lib/pkgconfig/
form.pc            libpcre2-32.pc     menu.pc            panel.pc
libbz2.pc          libpcre2-8.pc      ncurses++.pc       tinfo.pc
libpcre2-16.pc     libpcre2-posix.pc  ncurses.pc

No hits for term.h (not surprising):

$ /usr/gnu/bin/grep -IR 'term.h' ~/tmp/ok2delete/lib/pkgconfig/
$

Lots of hits for ncurses/ (expected):

$ /usr/gnu/bin/grep -IR '/ncurses' ~/tmp/ok2delete/lib/pkgconfig/ | grep -v http
/export/home/jwalton/tmp/ok2delete/lib/pkgconfig/form.pc:includedir=${prefix}/include/ncurses
/export/home/jwalton/tmp/ok2delete/lib/pkgconfig/ncurses++.pc:includedir=${prefix}/include/ncurses
/export/home/jwalton/tmp/ok2delete/lib/pkgconfig/panel.pc:includedir=${prefix}/include/ncurses
/export/home/jwalton/tmp/ok2delete/lib/pkgconfig/menu.pc:includedir=${prefix}/include/ncurses
/export/home/jwalton/tmp/ok2delete/lib/pkgconfig/tinfo.pc:includedir=${prefix}/include/ncurses
/export/home/jwalton/tmp/ok2delete/lib/pkgconfig/ncurses.pc:includedir=${prefix}/include/ncurses

Jeffrey Walton <noloader>
Mon 03 Aug 2020 01:06:51 PM UTC, comment #3: 

So it looks like ncurses' term.h is being overlooked in favour of /usr/include/term.h. This is a matter of providing the correct include file paths. I believe Zile is using the correct POSIX-mandated paths. (On my GNU/Linux system, /usr/include/term.h is provided by curses.)

The other thing that could be wrong is the curses detection (m4/ax_with_curses.m4): maybe it's detecting ncurses's curses.h, but not setting the include paths so that ncurses's term.h is used? ax_with_curses.m4 has been updated since the version included with Zile, but I can't see any changes in this area.

(src/term_curses.c is Zile's curses back end, the interface between Zile and curses; in the past, Zile had other ways of talking to the terminal.)

Reuben Thomas <rrt>
Group administrator
Mon 03 Aug 2020 12:54:41 PM UTC, comment #2: 

comment #1:

> ... no Zile code has been reached by the time you get these errors, and clearly it is finding curses.


I think its compiling Zile code.

The thing that looks odd (to me) is, Zile is compiling (for example) src/term_curses.c, but it is using system headers.

If I am parsing things correctly, it looks like Ncurses provides the header "ncurses/term.h":

$ ls ~/tmp/ok2delete/include/ncurses/
curses.h       cursesp.h      etip.h         ncurses.h      term_entry.h
cursesapp.h    cursesw.h      form.h         ncurses_dll.h  termcap.h
cursesf.h      cursslk.h      menu.h         panel.h        tic.h
cursesm.h      eti.h          nc_tparm.h     term.h         unctrl.h

-------------

$ gmake V=1
PACKAGE_NAME="Zile" /bin/perl -I./build-aux ./build-aux/mkfuncs.pl . src/basic.c src/bind.c src/buffer.c src/eval.c src/file.c src/funcs.c src/help.c src/killring.c src/line.c src/gc_veneer.c src/lisp.c src/macro.c src/redisplay.c src/registers.c src/search.c src/undo.c src/variables.c src/window.c
gmake  all-recursive
...

PACKAGE_NAME="Zile" /bin/perl -I./build-aux ./build-aux/mkfuncs.pl . src/basic.c src/bind.c src/buffer.c src/eval.c src/file.c src/funcs.c src/help.c src/killring.c src/line.c src/gc_veneer.c src/lisp.c src/macro.c src/redisplay.c src/registers.c src/search.c src/undo.c src/variables.c src/window.c
depbase=`echo src/term_curses.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -std=gnu99 -DHAVE_CONFIG_H -I.  -I./src -I./src -I./lib -I./lib -DPATH_DOCDIR="\"/export/home/jwalton/tmp/ok2delete/share/doc/zile\"" -I/export/home/jwalton/tmp/ok2delete/include -DNDEBUG   -g2 -O2 -m64 -march=native -fPIC -pthread -MT src/term_curses.o -MD -MP -MF $depbase.Tpo -c -o src/term_curses.o src/term_curses.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from src/term_curses.c:38:0:
/usr/include/term.h:1061:2: error: unknown type name 'SGTTY'
  SGTTY Ottyb,  /* original state of the terminal */
  ^
/usr/include/term.h:1195:3: error: conflicting types for 'tparm'
  tparm(char , long, long, long, long, long, long, long, long, long);
...

Jeffrey Walton <noloader>
Sun 02 Aug 2020 08:08:30 PM UTC, comment #1: 

Sorry if I'm being dim here, but I can't see what this has to do with Zile, as no Zile code has been reached by the time you get these errors, and clearly it is finding curses.

Reuben Thomas <rrt>
Group administrator
Sun 02 Aug 2020 07:29:59 PM UTC, original submission:  

Hi Everyone,

I'm attempting to build Zile 2.4.14 on Solaris 11.3 i86pc using x86_64-sun-solaris triplet.

Configure goes well, but make is failing with:

zile-2.4.14$ gmake
PACKAGE_NAME="Zile" /bin/perl -I./build-aux ./build-aux/mkfuncs.pl . src/basic.c src/bind.c src/buffer.c src/eval.c src/file.c src/funcs.c src/help.c src/killring.c src/line.c src/gc_veneer.c src/lisp.c src/macro.c src/redisplay.c src/registers.c src/search.c src/undo.c src/variables.c src/window.c
gmake  all-recursive
gmake[1]: Entering directory `/export/home/jwalton/Build-Scripts/zile-2.4.14'
Making all in lib
gmake[2]: Entering directory `/export/home/jwalton/Build-Scripts/zile-2.4.14/lib'
gmake  all-recursive
gmake[3]: Entering directory `/export/home/jwalton/Build-Scripts/zile-2.4.14/lib'
gmake[4]: Entering directory `/export/home/jwalton/Build-Scripts/zile-2.4.14/lib'
gmake[4]: Nothing to be done for `all-am'.
gmake[4]: Leaving directory `/export/home/jwalton/Build-Scripts/zile-2.4.14/lib'
gmake[3]: Leaving directory `/export/home/jwalton/Build-Scripts/zile-2.4.14/lib'
gmake[2]: Leaving directory `/export/home/jwalton/Build-Scripts/zile-2.4.14/lib'
Making all in .
gmake[2]: Entering directory `/export/home/jwalton/Build-Scripts/zile-2.4.14'
PACKAGE_NAME="Zile" /bin/perl -I./build-aux ./build-aux/mkfuncs.pl . src/basic.c src/bind.c src/buffer.c src/eval.c src/file.c src/funcs.c src/help.c src/killring.c src/line.c src/gc_veneer.c src/lisp.c src/macro.c src/redisplay.c src/registers.c src/search.c src/undo.c src/variables.c src/window.c
  CC       src/term_curses.o
In file included from src/term_curses.c:38:0:
/usr/include/term.h:1061:2: error: unknown type name 'SGTTY'
  SGTTY Ottyb,  /* original state of the terminal */
  ^
/usr/include/term.h:1195:3: error: conflicting types for 'tparm'
  tparm(char , long, long, long, long, long, long, long, long, long);
   ^
In file included from src/term_curses.c:30:0:
/export/home/jwalton/tmp/ok2delete/include/ncurses/curses.h:879:31: note: previous declaration of 'tparm' was here
 extern NCURSES_EXPORT(char ) tparm (NCURSES_CONST char , ...); /* special */
                               ^
In file included from src/term_curses.c:38:0:
/usr/include/term.h:1203:4: error: conflicting types for 'tigetstr'
   tigetstr(char ),
    ^
In file included from src/term_curses.c:30:0:
/export/home/jwalton/tmp/ok2delete/include/ncurses/curses.h:875:31: note: previous declaration of 'tigetstr' was here
 extern NCURSES_EXPORT(char ) tigetstr (NCURSES_CONST char );  /* implemented */
                               ^
In file included from src/term_curses.c:38:0:
/usr/include/term.h:1207:38: error: conflicting types for 'putp'
   tputs(char , int, int ()(char)), putp(char *),
                                      ^
In file included from src/term_curses.c:30:0:
/export/home/jwalton/tmp/ok2delete/include/ncurses/curses.h:876:28: note: previous declaration of 'putp' was here
 extern NCURSES_EXPORT(int) putp (const char );    / implemented */
                            ^
In file included from src/term_curses.c:38:0:
/usr/include/term.h:1208:21: error: conflicting types for 'tigetflag'
   tigetint(char ), tigetflag(char ), tigetnum(char *),
                     ^
In file included from src/term_curses.c:30:0:
/export/home/jwalton/tmp/ok2delete/include/ncurses/curses.h:873:28: note: previous declaration of 'tigetflag' was here
 extern NCURSES_EXPORT(int) tigetflag (NCURSES_CONST char );  / implemented */
                            ^
In file included from src/term_curses.c:38:0:
/usr/include/term.h:1208:40: error: conflicting types for 'tigetnum'
   tigetint(char ), tigetflag(char ), tigetnum(char *),
                                        ^
In file included from src/term_curses.c:30:0:
/export/home/jwalton/tmp/ok2delete/include/ncurses/curses.h:874:28: note: previous declaration of 'tigetnum' was here
 extern NCURSES_EXPORT(int) tigetnum (NCURSES_CONST char );  / implemented */
                            ^
In file included from src/term_curses.c:38:0:
/usr/include/term.h:1209:3: error: conflicting types for 'vidputs'
   vidputs(chtype, int (*)(char)), vidattr(chtype);
   ^
In file included from src/term_curses.c:30:0:
/export/home/jwalton/tmp/ok2delete/include/ncurses/curses.h:807:28: note: previous declaration of 'vidputs' was here
 extern NCURSES_EXPORT(int) vidputs (chtype, NCURSES_OUTC);  /* implemented */
                            ^
In file included from src/term_curses.c:38:0:
/usr/include/term.h:1211:26: error: macro "resetterm" passed 1 arguments, but takes just 0
 extern int resetterm(void), fixterm(void), saveterm(void),
                          ^
/usr/include/term.h:1211:41: error: macro "fixterm" passed 1 arguments, but takes just 0
 extern int resetterm(void), fixterm(void), saveterm(void),
                                         ^
/usr/include/term.h:1211:57: error: macro "saveterm" passed 1 arguments, but takes just 0
 extern int resetterm(void), fixterm(void), saveterm(void),
                                                         ^
gmake[2]: * [src/term_curses.o] Error 1

Jeffrey Walton <noloader>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #49612:  config.log.zip added by noloader (62KiB - application/zip - config.log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rrt (Posted a comment)
  • -email is unavailable- added by noloader (Submitted the item)
  • -email is unavailable- added by noloader
  •  

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-27 rrt StatusNone Fixed
        Open/ClosedOpen Closed
    2020-08-02 noloader Attached File- Added config.log.zip, #49612
        Carbon-Copy- Added noloader

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code