Menu

#406 xdvi fails to build w/ gcc-14

incorrect behaviour
open
nobody
None
3
2025-02-17
2024-07-04
No

Down here in the Debian bug tracking system it was noticed that xdvi fails to build when using gcc-14:

gcc -DHAVE_CONFIG_H -I. -I../../../texk/xdvik -I../../../texk/xdvik/gui -DPS_G -I/home/hille/gcc-14/texlive-bin-2024.20240313.70630+ds/Work/texk -I/home/hill/gcc-14/texlive-bin-2024.20240313.70630+ds/texk -I/usr/include/freetype2 -I/usrinclude/libpng16 -Wdate-time -D_FORTIFY_SOURCE=2 -Wimplicit -Wreturn-type -g-O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/hille/gcc-14/exlive-bin-2024.20240313.70630+ds=. -fstack-protector-strong -fstack-clash-protction -Wformat -Werror=format-security -fcf-protection -c -o gui/pagesel.o .././../texk/xdvik/gui/pagesel.c
../../../texk/xdvik/gui/pagesel.c: In function ‘xaw_update_list’:
../../../texk/xdvik/gui/pagesel.c:541:41: error: passing argument 2 of ‘XawListhange’ from incompatible pointer type [-Wincompatible-pointer-types]
541 | XawListChange(LIST_WIDGET, page_info.page_labels, 0,
| ~~~~~~~~~^~~~~~~~~~~~
| |
| char **
In file included from ../../../texk/xdvik/gui/pagesel.c:93:
/usr/include/X11/Xaw/List.h:170:27: note: expected ‘const char ’ but argumen tis of type ‘char
170 | _Xconst char **list,
| ^

The message is visible for a while now in the build logs, but until gcc-14 it seems to have been treated as warning. Please be so kind to have a look. Thank you!

Related

Bugs: #406

Discussion

  • Hilmar Preuße

    Hilmar Preuße - 2024-07-24

    I just noticed that the issue is specific to Debian and an incompatible change in libxaw7. Debian still has version 1.0.14, meanwhile the issue would not exist, when 1.0.16 would have been packaged.

    Here is the changelog from the libxaw source:

    commit d0fcbd9722ad691ca0b5873c98e8e9c236fa718b
    Author: Thomas E. Dickey dickey@invisible-island.net
    Date: Sun Mar 3 20:21:40 2024 -0500

    amend change to XawListChange()
    
    My previous commit in July 2019
    
      build-fixes when _CONST_X_STRING is defined
    
    modified the interface of XawListChange() to use "_Xconst char *"
    to fix builds when the Xt symbol _CONST_X_STRING is defined (which
    makes the String typedef "const").
    
    While this fixed building Xaw, clients which use Xaw were impacted.
    Changing that function to use String resolves both problems.
    
    (report by Karl Berry).
    
    Signed-off-by: Thomas E. Dickey <dickey@invisible-island.net>
    

    Feel free to close the issue,

     
  • karl berry

    karl berry - 2025-02-15

    The issue should not be closed.

    unfortunately, using String does not solve the problem in general. I suggested that in the thread around https://tug.org/pipermail/tex-k/2024-February/004012.html and it remains pointer-incompatible.

    I believe the only general fix suitable for upstream is a configure test to determine the type of the list parameter in the XawListChange function, and then cast to that type. The problem is that different systems have different incompatible types for that parameter, so no single type will do for the cast. (And that gcc made this tiny problem into an error, but there's nothing we can do about that.)

    Paul, maybe you would be up for working on this? (Unless you see some other fix, of course.) The problem gets reported over and over, e.g., recently from Nelson: https://www.math.utah.edu/pub/texlive-utah-2025/#centos10-x86_64

    Meanwhile, I added a comment in the source (gui/pagesel.c) about this. Maybe someone will be motivated to fix it. Though I have my doubts.

     
    • Paul Vojta

      Paul Vojta - 2025-02-15

      Unfortunately, I don't have any easy way to install gcc-14 (I'm using
      Debian-12 (bookworm, =stable), which doesn't have a gcc-14 package).

      However, looking in the various archives, I see that xdm-1.14 is compiling
      with -D_CONST_X_STRING
      (see https://gitlab.freedesktop.org/xorg/app/xdm/-/commit/2b451b9915e3a379974a3c2b5fe9d4798f0c136b)
      and then casts to _Xconst char :
      XawListChange (list, (_Xconst char
      ) newTable, size, 0, TRUE);

      I don't have much time to look into it further right now.

      Paul

      On Sat, Feb 15, 2025 at 06:17:05PM -0000, karl berry wrote:

      The issue should not be closed.

      unfortunately, using String does not solve the problem in general. I suggested that in the thread around https://tug.org/pipermail/tex-k/2024-February/004012.html and it remains pointer-incompatible.

      I believe the only general fix suitable for upstream is a configure test to determine the type of the list parameter in the XawListChange function, and then cast to that type. The problem is that different systems have different incompatible types for that parameter, so no single type will do for the cast. (And that gcc made this tiny problem into an error, but there's nothing we can do about that.)

      Paul, maybe you would be up for working on this? (Unless you see some other fix, of course.) The problem gets reported over and over, e.g., recently from Nelson: https://www.math.utah.edu/pub/texlive-utah-2025/#centos10-x86_64

      Meanwhile, I added a comment in the source (gui/pagesel.c) about this. Maybe someone will be motivated to fix it. Though I have my doubts.


      [bugs:#406] xdvi fails to build w/ gcc-14

      Status: open
      Group: incorrect behaviour
      Created: Thu Jul 04, 2024 06:52 AM UTC by Hilmar Preuße
      Last Updated: Wed Jul 24, 2024 09:16 PM UTC
      Owner: nobody

      Down here in the Debian bug tracking system it was noticed that xdvi fails to build when using gcc-14:

      gcc -DHAVE_CONFIG_H -I. -I../../../texk/xdvik -I../../../texk/xdvik/gui -DPS_G -I/home/hille/gcc-14/texlive-bin-2024.20240313.70630+ds/Work/texk -I/home/hill/gcc-14/texlive-bin-2024.20240313.70630+ds/texk -I/usr/include/freetype2 -I/usrinclude/libpng16 -Wdate-time -D_FORTIFY_SOURCE=2 -Wimplicit -Wreturn-type -g-O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/hille/gcc-14/exlive-bin-2024.20240313.70630+ds=. -fstack-protector-strong -fstack-clash-protction -Wformat -Werror=format-security -fcf-protection -c -o gui/pagesel.o .././../texk/xdvik/gui/pagesel.c
      ../../../texk/xdvik/gui/pagesel.c: In function ‘xaw_update_list’:
      ../../../texk/xdvik/gui/pagesel.c:541:41: error: passing argument 2 of ‘XawListhange’ from incompatible pointer type [-Wincompatible-pointer-types]
      541 | XawListChange(LIST_WIDGET, page_info.page_labels, 0,
      | ~~~~~~~~~^~~~~~~~~~~~
      | |
      | char **
      In file included from ../../../texk/xdvik/gui/pagesel.c:93:
      /usr/include/X11/Xaw/List.h:170:27: note: expected ‘const char ’ but argumen tis of type ‘char
      170 | _Xconst char **list,
      | ^

      The message is visible for a while now in the build logs, but until gcc-14 it seems to have been treated as warning. Please be so kind to have a look. Thank you!


      Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/xdvi/bugs/406/

      To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #406

      • Hilmar Preuße

        Hilmar Preuße - 2025-02-15

        The gcc-14 is in Debian testing and we (Debian) intend to release soon. As said: the incompatibility is present for a while now (see build log using gcc-13).
        Finally one could argue that changing the API of libXaw without doing an so-name bump could be treated as bug on libXaw side.

         
  • karl berry

    karl berry - 2025-02-15

    Thanks for the investigations, Paul. That sort of -D + cast does not look like it could work for TL. I still don't see a plausible fix short of a configure test :(.

     
  • karl berry

    karl berry - 2025-02-17

    I got tired of looking at this, so I wrote the little bit of shell code to simplistically guess the type of the list parameter to XawListChange. I just committed it to TL, r74082. Maybe it will work in practice? But I won't be surprised if I overlooked something that makes it fail. The diff is attached, I hope.

     

Log in to post a comment.

MongoDB Logo MongoDB