kodi: update to 19.3.

[Goorzhel]

Update patches to match. (Is there a way to do that other than cloning the upstream, making the changes by hand, and doing a git diff?)

Testing the changes

I briefly tested the changes in this PR. It installs fine on a Pi 4 (aarch64), although there were setup pains — on both 19.0 and .3 — that forced me toward LibreELEC instead.

[Goorzhel]

Ah, I hadn't tested musl, even though all the patches were presumably for it. Good job, me. Taking a look.

[Goorzhel]

It's something to do with fpos, which is being patched in fix-fileemu.patch:

../xbmc/cores/DllLoader/exports/emu_msvcrt.cpp: In function 'int dll_fgetpos64(FILE*, fpos_t*)':
../xbmc/cores/DllLoader/exports/emu_msvcrt.cpp:1497:33: error: no match for 'operator=' (operand types are 'fpos_t' and 'int64_t' {aka 'long int'})
 1497 |       *pos = pFile->GetPosition();
      |                                 ^
In file included from ../xbmc/cores/DllLoader/exports/emu_msvcrt.cpp:10:
/usr/aarch64-linux-musl/usr/include/stdio.h:54:15: note: candidate: 'constexpr _G_fpos64_t& _G_fpos64_t::operator=(const _G_fpos64_t&)'
   54 | typedef union _G_fpos64_t {
      |               ^~~~~~~~~~~
/usr/aarch64-linux-musl/usr/include/stdio.h:54:15: note:   no known conversion for argument 1 from 'int64_t' {aka 'long int'} to 'const _G_fpos64_t&'
/usr/aarch64-linux-musl/usr/include/stdio.h:54:15: note: candidate: 'constexpr _G_fpos64_t& _G_fpos64_t::operator=(_G_fpos64_t&&)'
/usr/aarch64-linux-musl/usr/include/stdio.h:54:15: note:   no known conversion for argument 1 from 'int64_t' {aka 'long int'} to '_G_fpos64_t&&'
../xbmc/cores/DllLoader/exports/emu_msvcrt.cpp: In function 'int dll_fsetpos64(FILE*, const fpos_t*)':
../xbmc/cores/DllLoader/exports/emu_msvcrt.cpp:1513:28: error: cannot convert 'const fpos_t' to '__off64_t' {aka 'long int'}
 1513 |       if (dll_lseeki64(fd, *pos, SEEK_SET) >= 0)
      |                            ^~~~
      |                            |
      |                            const fpos_t
../xbmc/cores/DllLoader/exports/emu_msvcrt.cpp:654:44: note:   initializing argument 2 of '__off64_t dll_lseeki64(int, __off64_t, int)'
  654 |   __off64_t dll_lseeki64(int fd, __off64_t lPos, int iWhence)
      |                                  ~~~~~~~~~~^~~~

[Goorzhel]

  #if !defined(TARGET_POSIX) || defined(TARGET_DARWIN) || defined(TARGET_FREEBSD) || defined(TARGET_ANDROID) || !defined(__GLIBC__)
        *pos = pFile->GetPosition();
  #else
        pos->__pos = pFile->GetPosition();
  #endif

So, the first branch seems to treat pos as an integer (I think), or at least something that can be assigned an integer, but that's not the case in musl:

  typedef union _G_fpos64_t {
          char __opaque[16];
          long long __lldata;
          double __align;
  } fpos_t;

And the other branch also won't work because there's no __pos member.

I dunno, I think I'm going to need someone that groks C++ to take a look at this, because I'm in over my head here.

EDIT: I had missed two crucial type-casting lines.

[ericonr]

The truth is this shouldn't be touching fpos_t at all...

Please squash the commits!

[Goorzhel]

The truth is this shouldn't be touching fpos_t at all...

Hmm, out of curiosity, why's that?

[ericonr]

Because it's an opaque structure, you aren't supposed to poke inside its bits.

[marmeladema]

Superseded by #36526

[the-maldridge]

Obsoleted by #36526.