Arch Linux User Repository

Indeed, that code is straight-up broken on 64-bit platforms and GCC is right to reject it. Pushed a patch to circumvent the issue, but the fix should really be upstreamed, which I may get around to later this week.

Now upstream is failing to build due to new warnings in GCC 14, due to passing a uint32_t by pointer to a parameter asking for a pointer to size_t.

In file included from meta/ubi_hx.c:5:
meta/../util/chunks.h:38:127: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'uint32_t *' {aka 'unsigned int *'}
   38 | int find_chunk_riff_ve(STREAMFILE* sf, uint32_t chunk_id, off_t start_offset, size_t max_size, off_t* p_chunk_offset, size_t* p_chunk_size, int big_endian);
      |                                                                                                                       ~~~~~~~~^~~~~~~~~~~~
meta/ubi_hx.c:396:103: error: passing argument 6 of 'find_chunk_riff_ve' from incompatible pointer type [-Wincompatible-pointer-types]
  396 |             if (!find_chunk_riff_ve(sf, 0x61746164,riff_offset + 0x0c,riff_size - 0x0c, &chunk_offset,&chunk_size, hx->big_endian)) {
      |                                                                                                       ^~~~~~~~~~~
      |                                                                                                       |
      |                                                                                                       uint32_t * {aka unsigned int *}
meta/../util/chunks.h:38:127: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'uint32_t *' {aka 'unsigned int *'}
   38 | int find_chunk_riff_ve(STREAMFILE* sf, uint32_t chunk_id, off_t start_offset, size_t max_size, off_t* p_chunk_offset, size_t* p_chunk_size, int big_endian);
      |                                                                                                                       ~~~~~~~~^~~~~~~~~~~~
make[2]: *** [Makefile.autotools:2704: meta/ubi_hx.lo] Error 1

Alright, well it seems that your plugin does need the api.h so I added it here.

@Deewiant: I'm not really involved with the project any more. Though I do occasionally use it still. I don't know that the api.h was really needed by a plugin, I may be able to get away without it.

I made a deadbeef plugin, it requires this AUR package to build, and links to it dynamically.

https://bitbucket.org/losnoco/deadbeef_plugins - under plugins/vgm

@kode54 You might know something I don't but as far as I can tell those aren't really used, at least yet. I've based the headers to install on delivering a working vgmstream.h, which seems like the "entry point" to the public API. api.h currently doesn't do anything other than include base/plugins.h, which was apparently moved from plugins.h recently but that one has never been installed here either.

I guess the problem is that this thing isn't really a library in the sense of being intended for use by other projects. Or if it is, I don't understand where the line is between public API and internals.

(As a side note I tried to do a CMake conversion of the PKGBUILD but that one apparently doesn't install a shared library at all and just statically links both of the binaries, so it's in even worse shape from my perspective...)

New headers for the install headers patch:

api.h
base/plugins.h

@jkl Yep, that's exactly it. Updated.

This broke again with latest HEAD because the celt symbols were renamed. Need something like the following to fix it.

@@ -78,7 +78,7 @@ celt_symbols=(
 build() {
   celt06_cflags="$CFLAGS -fPIC"
   for sym in ${celt_symbols[@]}; do
-    celt06_cflags+=" -D$sym=$(sed 's/[^_]\+/&_0061/' <<< $sym)"
+    celt06_cflags+=" -D$sym=${sym}_0061"
   done
   celt11_cflags="${celt06_cflags//_0061/_0110} -DCUSTOM_MODES=1"

Fixed now. (You may have been unlucky, the update that broke it came just a few hours before your message.)

the makefile.autotools.am patch is failing, causing the build to fail.