Fails to build with gcc 14

[plorenzo]

Hi,

I know you are aware of the problem and it was already discussed
in the devel mailing list, just need an issue to link to the
Debian Bug tracking system.
Also, this is now considered a blocker for the next Debian release so if it isn't fixed around December2024/Gen2025, mplayer will likely miss the next Debian stable release.

links:

Debian bug #1075294

​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075294

patch on mplayer-dev

​https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2024-April/074173.html

I haven't yet tested the patch, what's the risk if I use that to temporary build the deb package, new bugs or also security holes?

Thanks,
Lorenzo

[beastd]

Hi Lorenzo,

thanks for opening this ticket.

I'm optimistic we can get MPlayer to compile with GCC14.

As I'm really low on time at least for a month from now, it will probably take about 2 months minimum to fix. Maybe more realistically 3 months with review, rework, commits...

TL;DR: Would be good if you give the patch a chance. Maybe there is more missing in regard to the Debian builds and their configuration. I would be glad to hear about it should it work or not! I would not recommend to distribute the results though.

plorenzo wrote:

I haven't yet tested the patch, what's the risk if I use that to temporary build the deb package, new bugs or also security holes?

That's a bit hard to say. I see mainly 2 risks

1. The patch hasn't really seen much of review. Maybe some bad mistakes crept in by accident.
2. Everywhere we touch on undefined behavior (UB), there is a chance the compiler will do something wrong. Doesn't happen most of the time, but there were quite a few cases documented. Some with security impact.

Regarding risk 2 I hope the patch itself shouldn't really introduce newly undefined behavior that wasn't there previously. Just makes it more visible in the code and less visible in the compiler output because the warnings/errors are silenced.

So there is only the general risk that GCC14 will lay out the UB in ways that are less favorable for us or even dangerous.

[plorenzo]

Hi,
I tested a slightly refreshed version of the patch [1] with svn38638; builds fine
on amd64, fails on i386 with the following error

libmpcodecs/vd_qtvideo.c:132:20: error: assignment to 'char (*)(Size)' {aka 'char (*)(int)'} from incompatible pointer type 'OSErr (*)(Size)' {aka 'short int (*)(int)'} [-Wincompatible-pointer-types]

132 | NewHandleClear = (OSErr(*)(Size))GetProcAddress(handler, "NewHandleClear");

|

full build log in [2]
other than that, on amd64 mplayer seems to work fine (tested only few video files though)

Thanks,
Lorenzo

[1] ​https://salsa.debian.org/multimedia-team/mplayer/-/blob/next/debian/patches/0205-fix-FTBFS-gcc14.patch?ref_type=heads
[2] ​https://salsa.debian.org/multimedia-team/mplayer/-/jobs/6242311/raw

[beastd]

Thanks for trying the patch!

Unfortunately I was not able to continue work on this yet.

Hope I can make some time for it soon.

[beastd]

Since today most stuff is fixed starting with MPlayer SVN r38660 .

There are probably still some problems with x86 32bit and maybe on some other platforms.

Will try to look into the specific build problem you quoted above next.

[marillat@…]

I see this issue with r38660 Debian unstable amd64 gcc 14.2.0

In file included from libvo/vo_mga.c:52:
libvo/mga_template.c: In function 'draw_slice_g200':
libvo/mga_template.c:80:28: error: passing argument 2 of 'sws_scale' from incompatible pointer type [-Wincompatible-pointer-types]
   80 |         sws_scale(sws_ctx, image, stride, y, height, dst, dst_stride);
      |                            ^~~~~
      |                            |
      |                            uint8_t ** {aka unsigned char **}
In file included from libvo/mga_template.c:22:

[marillat@…]

I see this issue with r38660 Debian unstable i386 gcc 14.2.0
with mga driver disabled

libmpcodecs/ve_nuv.c: In function 'put_image':
libmpcodecs/ve_nuv.c:155:34: error: passing argument 4 of 'lzo1x_1_compress' from incompatible pointer type [-Wincompatible-pointer-types]
  155 |                            zdata,&zlen,vf->priv->zmem);
      |                                  ^~~~~
      |                                  |
      |                                  size_t * {aka unsigned int *}
In file included from libmpcodecs/ve_nuv.c:41:
/usr/include/lzo/lzo1x.h:75:58: note: expected 'lzo_uint *' {aka 'long unsigned int *'} but argument is of type 'size_t *' {aka 'unsigned int *'}
   75 |                                 lzo_bytep dst, lzo_uintp dst_len,
      |                                                          ^
libmpcodecs/ve_nuv.c:180:43: error: passing argument 4 of 'lzo1x_1_compress' from incompatible pointer type [-Wincompatible-pointer-types]
  180 |       r = lzo1x_1_compress(data,len,zdata,&zlen,vf->priv->zmem);
      |                                           ^~~~~
      |                                           |
      |                                           size_t * {aka unsigned int *}
/usr/include/lzo/lzo1x.h:75:58: note: expected 'lzo_uint *' {aka 'long unsigned int *'} but argument is of type 'size_t *' {aka 'unsigned int *'}
   75 |                                 lzo_bytep dst, lzo_uintp dst_len,
      |                                                          ^
make: *** [Makefile:729: libmpcodecs/ve_nuv.o] Error 1

[plorenzo]

Hi, quick update:
I've applied the patch from
​https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2024-October/074231.html
and the error I reported for vd_qtvideo.c is fixed.
The build on i386 now fails with the same error in ve_nuv.c reported by Marillat

[ib]

Try:

--- a/libmpcodecs/ve_nuv.c
+++ b/libmpcodecs/ve_nuv.c
@@ -125,7 +125,7 @@
   uint8_t* data = vf->priv->buffer + FRAMEHEADERSIZE;
   uint8_t* zdata = vf->priv->zbuffer + FRAMEHEADERSIZE;
   int len = 0, r;
-  size_t zlen = 0;
+  lzo_uint zlen = 0;
 
   memset(header, 0, FRAMEHEADERSIZE); // Reset the header
   if(vf->priv->lzo)

[marillat@…]

Issue in comment 5 has been fixed with a rebuild of r38664
Proposed patch from plorenzo fix the build with 32 bits arches

But I see one issue with powerpc arch :

libmpcodecs/vf_scale.c: In function 'scale':
libmpcodecs/vf_scale.c:432:16: error: assignment to 'uint8_t *' {aka 'unsigned char *'} from incompatible pointer type 'uint32_t *' {aka 'unsigned int *'} [-Wincompatible-pointer-types]
  432 |         src2[1]= pal2;
      |                ^
libmpcodecs/vf_scale.c: At top level:
libmpcodecs/vf_scale.c:733:50: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  733 |   {"presize", 0, CONF_TYPE_OBJ_PRESETS, 0, 0, 0, &size_preset},
      |                                                  ^
make: *** [Makefile:729: libmpcodecs/vf_scale.o] Error 1

[plorenzo]

Hi Ingo, yes with your patch I can build on i386.
Thanks :)

[ib]

Replying to plorenzo:

with your patch I can build on i386.

Patch has been committed to svn.

[marillat@…]

The problem for powerpc come from commit 38647 "explicit pointer casts"

Index: libmpcodecs/vf_scale.c
===================================================================
--- libmpcodecs/vf_scale.c	(révision 38201)
+++ libmpcodecs/vf_scale.c	(révision 38647)
@@ -439,14 +439,14 @@
         int src_stride2[MP_MAX_PLANES]={2*src_stride[0], 2*src_stride[1], 2*src_stride[2], 2*src_stride[3]};
         int dst_stride2[MP_MAX_PLANES]={2*dst_stride[0], 2*dst_stride[1], 2*dst_stride[2], 2*dst_stride[3]};
 
-        sws_scale(sws1, src2, src_stride2, y>>1, h>>1, dst2, dst_stride2);
+        sws_scale(sws1, (const uint8_t *const *)src2, src_stride2, y>>1, h>>1, dst2, dst_stride2);
         for(i=0; i<MP_MAX_PLANES; i++){
             src2[i] += src_stride[i];
             dst2[i] += dst_stride[i];
         }
-        sws_scale(sws2, src2, src_stride2, y>>1, h>>1, dst2, dst_stride2);
+        sws_scale(sws2, (const uint8_t *const *)src2, src_stride2, y>>1, h>>1, dst2, dst_stride2);
     }else{
-        sws_scale(sws1, src2, src_stride, y, h, dst, dst_stride);
+        sws_scale(sws1, (const uint8_t *const *)src2, src_stride, y, h, dst, dst_stride);
     }
 

But as powerpc is bigendian the code above these changes have not been modified.

#if HAVE_BIGENDIAN
    uint32_t pal2[256];
    if (src[1] && !src[2]){
        int i;
        for(i=0; i<256; i++)
            pal2[i]= bswap_32(((uint32_t*)src[1])[i]);
        src2[1]= pal2;
    }
#endif

[beastd]

Replying to marillat@…:
[...]

But as powerpc is bigendian the code above these changes have not been modified.

#if HAVE_BIGENDIAN
    uint32_t pal2[256];
    if (src[1] && !src[2]){
        int i;
        for(i=0; i<256; i++)
            pal2[i]= bswap_32(((uint32_t*)src[1])[i]);
        src2[1]= pal2;
    }
#endif

So appying the following diff fixes the build for powerpc?

libmpcodecs/vf_scale.c

@@ -429 +429 @@
         int i;
         for(i=0; i<256; i++)
             pal2[i]= bswap_32(((uint32_t*)src[1])[i]);
-        src2[1]= pal2;
+        src2[1]= (uint8_t *)pal2;
     }
 #endif
 

[marillat@…]

Thanks beastd, this patch fix this issue.

[beastd]

Replying to marillat@…:

Thanks beastd, this patch fix this issue.

OK, thanks for confirming.

Committed as SVN r38668 .

[beastd]

Lorenzo and Christian,
with current MPlayer SVN r38668 are there still problems to build with GCC 14?
On some specific os/arch, maybe?

[marillat@…]

For me it's OK

Christian

[plorenzo]

Hi,

I think patch from KO Myung-Hun in mplayer-dev list is still missing and it was necessary to build on i386
​https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2024-October/074231.html

other than that this issue looks fixed.
Thanks!

Lorenzo

[marillat@…]

I did this morning a SVN r38668 build for i386 without problem.

Also Debian did a SVn r38638 build 2 days ago without problem.

​https://buildd.debian.org/status/package.php?p=mplayer&suite=sid

[plorenzo]

Hi,
Debian svn r38638 has the patch from KO Myung-Hun applied (it's 0207):
​https://salsa.debian.org/multimedia-team/mplayer/-/tree/master/debian/patches?ref_type=heads

for testing I just removed the patch and pushed in Salsa to trigger the CI, and it still fails on i386
​https://salsa.debian.org/multimedia-team/mplayer/-/jobs/6802333

Not sure why it fails in Debian builds but not in Marillat's, maybe there are different config switches or there is a slightly different build environment?

Lorenzo

[beastd]

Hi Lorenzo!

Replying to plorenzo:

Debian svn r38638 has the patch from KO Myung-Hun applied (it's 0207):
​https://salsa.debian.org/multimedia-team/mplayer/-/tree/master/debian/patches?ref_type=heads

for testing I just removed the patch and pushed in Salsa to trigger the CI, and it still fails on i386
​https://salsa.debian.org/multimedia-team/mplayer/-/jobs/6802333

Hmm. Maybe I'm missing something, but do you have specific reason to build from r38638?

After that came most of GCC14 fixes:

1. configure: disable Vulkan encoders
2. configure: remove -ffast-math
3. configure: enable DOVI encoder
4. configure: replace AV*putFormat with FF*
5. libaf/af_lavcresample: explicit pointer casts
6. libmpcodecs/ad_spdif: fix type of argument
7. libmpcodecs/vd_ffmpeg: explicit pointer casts
8. libmpcodecs/vf_pp: explicit pointer casts
9. libmpcodecs/vf_scale: explicit pointer casts
10. libmpcodecs/vf_screenshot: explicit pointer casts
11. libmpdemux/demux_film: explicit pointer casts
12. libmpdemux/demux_lavf: explicit pointer casts
13. libmpdemux/muxer_avi: explicit pointer casts
14. libvo/vo_aa: explicit pointer casts
15. libvo/vo_matrixview: explicit pointer casts
16. libvo/vo_x11: explicit pointer casts
17. loader/qtx/qtxsdk/components: explicit pointer casts
18. mp_msg: explicit pointer casts
19. mplayer: explicit pointer casts
20. sub/sub: explicit pointer casts
21. sub/spudec: explicit pointer casts
22. libvo/gl_common: fix incompatible pointer types
23. ao_dart, ao_kai: fix compilation due to switch from AVFifoBuffer to AVFifo
24. osdep/mmap.h: define MAP_FAILED if necessary
25. configure: define _EMX_SOURCE on OS/2
26. Check the return value of malloc() to avoid a NULL pointer dereference.
27. Use correct type to define the variable passed to lzo1x_1_compress().
28. configure: remove -Zomf from flags when checking extern symbol prefix on OS/2
29. M_PI is not mandated by the C standard.
30. libmpcodecs/vf_scale: Fix a build problem on big endian

Could you try a build from r38668 possibly with the mentioned patch from KO Myung-Hun applied on top?

[plorenzo]

Hi beastd,

Hmm. Maybe I'm missing something, but do you have specific reason to build from r38638?

After that came most of GCC14 fixes:

There is some overhead in fetching a new upstream svn snapshot in Debian packaging (people need to review it but also git workflow is more complex) so I was waiting for all gcc14 patches to be merged upstream before that (ideally I would like to wait as close as possible to the start of the Debian release process)

The Debian r38638 version is misleading, it's in fact r38638 + all gcc14 patches posted in mplayer dev list and here, sorry for confusion.

Could you try a build from r38668 possibly with the mentioned patch from KO Myung-Hun applied on top?

I did, patch from komh is still needed on i386; with patch applied on top of r38668 it builds fine on amd64 and i386.
i386 build logs, with patch:
​https://salsa.debian.org/Lorenzo.ru.g-guest/mplayer/-/jobs/6827271

without patch:
​https://salsa.debian.org/Lorenzo.ru.g-guest/mplayer/-/jobs/6827787

Lorenzo