[bug#75518] Motif build failure

  Hi,

Rutherther <rutherther@ditigal.xyz> writes:

> Hi, I've tried looking at one of the failing packages - motif.

The error looks like this:

--8<---------------cut here---------------start------------->8---
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../include -I.. -I./.. -DXMBINDDIR_FALLBACK=\"/gnu/store/lm1p1w0x29w2ypvc8g8nj6k7vharz927-motif-2.3.8-0.59858b0/lib/X11/bindings\" -DINCDIR=\"/gnu/store/lm1p1w0x29w2ypvc8g8nj6k7vharz927-motif-2.3.8-0.59858b0/include/X11\" -DLIBDIR=\"/gnu/store/lm1p1w0x29w2ypvc8g8nj6k7vharz927-motif-2.3.8-0.59858b0/lib/X11\" -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -g -O2 -Wall -g -fno-strict-aliasing -Wno-unused -Wno-comment -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -MT XpmWrFFrDat.lo -MD -MP -MF .deps/XpmWrFFrDat.Tpo -c XpmWrFFrDat.c  -fPIC -DPIC -o .libs/XpmWrFFrDat.o
XpmCrBufFrI.c: In function ‘XmeXpmCreateBufferFromXpmImage’:
XpmCrBufFrI.c:155:5: error: implicit declaration of function ‘strcpy’ [-Wimplicit-function-declaration]
  155 |     strcpy(ptr, buf);
      |     ^~~~~~
XpmCrBufFrI.c:47:1: note: include ‘<string.h>’ or provide a declaration of ‘strcpy’
   46 | #include "XpmI.h"
  +++ |+#include <string.h>
   47 | 
XpmCrBufFrI.c:155:5: warning: incompatible implicit declaration of built-in function ‘strcpy’ [-Wbuiltin-declaration-mismatch]
  155 |     strcpy(ptr, buf);
      |     ^~~~~~
XpmCrBufFrI.c:155:5: note: include ‘<string.h>’ or provide a declaration of ‘strcpy’
XpmCrBufFrI.c: In function ‘WriteColors’:
XpmCrBufFrI.c:292:9: error: implicit declaration of function ‘strncpy’ [-Wimplicit-function-declaration]
  292 |         strncpy(s, *defaults++, cpp);
      |         ^~~~~~~
XpmCrBufFrI.c:292:9: note: include ‘<string.h>’ or provide a declaration of ‘strncpy’
XpmCrBufFrI.c:292:9: warning: incompatible implicit declaration of built-in function ‘strncpy’ [-Wbuiltin-declaration-mismatch]
XpmCrBufFrI.c:292:9: note: include ‘<string.h>’ or provide a declaration of ‘strncpy’
XpmCrBufFrI.c:312:9: warning: incompatible implicit declaration of built-in function ‘strcpy’ [-Wbuiltin-declaration-mismatch]
  312 |         strcpy(s, "\",\n");
      |         ^~~~~~
XpmCrBufFrI.c:312:9: note: include ‘<string.h>’ or provide a declaration of ‘strcpy’
XpmCrBufFrI.c:316:45: error: implicit declaration of function ‘strlen’ [-Wimplicit-function-declaration]
  316 |            (*data_size + l - *used_size) <= strlen(buf))
      |                                             ^~~~~~
XpmCrBufFrI.c:316:45: note: include ‘<string.h>’ or provide a declaration of ‘strlen’
--8<---------------cut here---------------end--------------->8---

This is easily addressed with the attached patch.

Unfortunately there are additional failures afterwards:

--8<---------------cut here---------------start------------->8---
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../include -I.. -I./.. -DXMBINDDIR_FALLBACK=\"/gnu/store/jww518240g0h9ffmbn1c3069ly829mhw-motif-2.3.8-0.59858b0/lib/X11/bindings\" -DINCDIR=\"/gnu/store/jww518240g0h9ffmbn1c3069ly829mhw-motif-2.3.8-0.59858b0/include/X11\" -DLIBDIR=\"/gnu/store/jww518240g0h9ffmbn1c3069ly829mhw-motif-2.3.8-0.59858b0/lib/X11\" -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -g -O2 -Wall -g -fno-strict-aliasing -Wno-unused -Wno-comment -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -MT DrawUtils.lo -MD -MP -MF .deps/DrawUtils.Tpo -c DrawUtils.c  -fPIC -DPIC -o .libs/DrawUtils.o
In file included from TabStack.c:43:
TabStack.c: In function ‘QueryGeometry’:
../Xm/TabStackP.h:140:66: error: passing argument 1 of ‘_XmTabBoxStackedGeometry’ from incompatible pointer type [-Wincompatible-pointer-types]
  140 | #define XmTabStack_tab_box(w) (((XmTabStackWidget)(w))->tab_stack.tab_box)
      |                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
      |                                                                  |
      |                                                                  Widget {aka struct _WidgetRec *}
TabStack.c:1641:42: note: in expansion of macro ‘XmTabStack_tab_box’
 1641 |                 _XmTabBoxStackedGeometry(XmTabStack_tab_box(tab), width,
      |                                          ^~~~~~~~~~~~~~~~~~
TabStack.c:74:45: note: expected ‘XmTabBoxWidget’ {aka ‘struct _XmTabBoxRec *’} but argument is of type ‘Widget’ {aka ‘struct _WidgetRec *’}
   74 | extern void _XmTabBoxStackedGeometry _ARGS((XmTabBoxWidget, int, XRectangle *));
      |                                             ^~~~~~~~~~~~~~
TabStack.c:60:18: note: in definition of macro ‘_ARGS’
   60 | #define _ARGS(a) a
      |                  ^
--8<---------------cut here---------------end--------------->8---

I tried to build with ‘-std=c99’ (which is supposedly lower than the
default for GCC 14) but that didn’t help.

We could also check what other distros are doing.

Ludo’.
  

An update: I have just pushed these commits to ‘core-packages-team’:

  0a9e9e158b gnu: motif: Build with GCC 11.
  93d5c354c4 gnu: gcc: Fix compilation of libstdc++ for GCC 7 to 13.

They fix all these GCC versions (except GCC 13, which has other build
problems) and the infamous Motif problem, using GCC 11 as Rutherther
suggested before.

We’re making progress!

Ludo’.
  

Am Wed, Jun 11, 2025 at 11:27:16PM +0200 schrieb Ludovic Courtès:
> We’re making progress!

Thanks for that!

I have rebased on commit 601ed9166ea264f7ee49d55f3a7f2a24a9cb8746 ,
which is known to the data service and follows the mesa-updates merge.

Andreas
  

Hi,

Andreas Enge <andreas@enge.fr> writes:

> I have rebased on commit 601ed9166ea264f7ee49d55f3a7f2a24a9cb8746 ,
> which is known to the data service and follows the mesa-updates merge.

Nice; <https://ci.guix.gnu.org/jobset/core-packages-team> is now
building the full package set, for x86_64-linux-only for now.

We’ll have to squash or do something with the commits that read
“Partially revert …” at the beginning of this branch.

Thanks!

Ludo’.
  

Ludovic Courtès writes:

Hello,

> Andreas Enge <andreas@enge.fr> writes:
>
>> I have rebased on commit 601ed9166ea264f7ee49d55f3a7f2a24a9cb8746 ,
>> which is known to the data service and follows the mesa-updates merge.
>
> Nice; <https://ci.guix.gnu.org/jobset/core-packages-team> is now
> building the full package set, for x86_64-linux-only for now.

Yay!

> We’ll have to squash or do something with the commits that read
> “Partially revert …” at the beginning of this branch.

I don't think so; these are re-applies of [bits of] cleanups that were
applied and [partially] reverted much earlier, because these bits led
to world rebuilds (for non-x86 archictectures iirc).

Greetings,
Janneke
  

Ludovic Courtès <ludo@gnu.org> writes:

> An update: I have just pushed these commits to ‘core-packages-team’:
>
>   0a9e9e158b gnu: motif: Build with GCC 11.
>   93d5c354c4 gnu: gcc: Fix compilation of libstdc++ for GCC 7 to 13.
>
> They fix all these GCC versions (except GCC 13, which has other build
> problems) and the infamous Motif problem, using GCC 11 as Rutherther
> suggested before.

https://codeberg.org/guix/guix/commit/e02992a8b095641717ffb1cc49a6fe4571afc667

The problems of gcc 13 seem to be the same as those of gcc 14. So I also
applied the patch-tzdb.cc phase to gcc 13. I build clang-runtime-18
and it seems there is no problem.

>
> We’re making progress!
>
> Ludo’.
  

Hi,

Janneke Nieuwenhuizen <janneke@gnu.org> writes:

>> We’ll have to squash or do something with the commits that read
>> “Partially revert …” at the beginning of this branch.
>
> I don't think so; these are re-applies of [bits of] cleanups that were
> applied and [partially] reverted much earlier, because these bits led
> to world rebuilds (for non-x86 archictectures iirc).

Oh OK, then we’re good (I thought they were leftovers from the initial
work on the branch).

Thanks!

Ludo’.