Opened 2 months ago
Last modified 3 days ago
#70720 new defect
sox @14.4.2_4: error: incompatible function pointer types initializing 'sox_format_handler_seek' (aka 'int (*)(struct sox_format_t *, unsigned long)') with an expression of type 'int (sox_format_t *, uint64_t)' (aka 'int (struct sox_format_t *, unsigned long long)') [-Wincompatible-function-pointer-types]
Reported by: | tthoma24 (Teddy Thomas) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.10.1 |
Keywords: | sequoia | Cc: | MaurizioLoreti, fracai |
Port: | sox |
Description
Despite an updated Xcode 16 RC and Command Line Tools and a functional clang, the port fails to build with the below error on an Intel-based Mac. Full build log is attached.
:info:build skelform.c:214:5: error: incompatible function pointer types initializing 'sox_format_handler_seek' (aka 'int (*)(struct sox_format_t *, unsigned long)') with an expression of type 'int (sox_format_t *, uint64_t)' (aka 'int (struct sox_format_t *, unsigned long long)') [-Wincompatible-function-pointer-types] :info:build 214 | seek, encodings, NULL, sizeof(priv_t) :info:build | ^~~~ :info:build 1 warning and 1 error generated. :info:build make[1]: *** [libsox_la-skelform.lo] Error 1 :info:build make[1]: *** Waiting for unfinished jobs....
Attachments (1)
Change History (10)
Changed 2 months ago by tthoma24 (Teddy Thomas)
comment:1 Changed 4 weeks ago by edward-elhauge
I have a similar error on arm64 Sequoia 15.0.1 / Hardware M2 MacMini
:info:build skelform.c:214:5: error: incompatible function pointer types initializing 'sox_format_handler_seek' (aka 'int (*)(struct sox_format_t *, unsigned long)') with an expression of type 'int (sox_format_t *, uint64_t)' (aka 'int (struct sox_format_t *, unsigned long long)') [-Wincompatible-function-pointer-types] :info:build 214 | seek, encodings, NULL, sizeof(priv_t) :info:build | ^~~~ :info:build 6 warnings generated. :info:build 1 warning and 1 error generated.
comment:2 Changed 4 weeks ago by MaurizioLoreti
Me too, same error; MacPorts 2.10.2, Sequoia 15.0.1.
comment:3 Changed 4 weeks ago by MaurizioLoreti
Cc: | MaurizioLoreti added |
---|
comment:4 Changed 3 weeks ago by fracai
Cc: | fracai added |
---|
comment:5 Changed 3 weeks ago by ryandesign (Ryan Carsten Schmidt)
Summary: | sox @14.4.2_4 Fails to build on macOS Sequoia 15 RC → sox @14.4.2_4: error: incompatible function pointer types initializing 'sox_format_handler_seek' (aka 'int (*)(struct sox_format_t *, unsigned long)') with an expression of type 'int (sox_format_t *, uint64_t)' (aka 'int (struct sox_format_t *, unsigned long long)') [-Wincompatible-function-pointer-types] |
---|
comment:6 follow-up: 7 Changed 3 weeks ago by ryandesign (Ryan Carsten Schmidt)
This problem should probably be reported to the developers of sox.
This problem might be what this sox_ng commit is fixing. We could try backporting that or we might consider retiring the sox port and making one for sox_ng instead. sox may be dead; its last release was in 2015.
comment:7 Changed 3 weeks ago by edward-elhauge
Replying to ryandesign:
This problem might be what this sox_ng commit is fixing. We could try backporting that or we might consider retiring the sox port and making one for sox_ng instead. sox may be dead; its last release was in 2015.
It looks like the right fix to the right function. sox_ng would be great, if was backward compatible. My true interest is in the upward dependency to py310-transformers, and py310-torchaudio (which are part of the the pytorch ecosystem).
I also notice that tovid, kdenlive and mlt depend on sox.
comment:8 Changed 3 days ago by jacobvosmaer (Jacob Vosmaer)
This seems to work:
--- Portfile.orig 2024-11-05 11:45:10 +++ Portfile 2024-11-05 11:45:54 @@ -28,7 +28,8 @@ port:pkgconfig patchfiles patch-curl.diff \ - yosemite-libtool.patch + yosemite-libtool.patch \ + uint64_t.diff platform darwin 11 { # System grep fails: "grep: Regular expression too big"
Where uint64_t.diff is:
diff --git a/src/sox.h b/src/sox.h index 155742e..520f5c4 100644 --- src/sox.h.orig +++ src/sox.h @@ -22,6 +22,7 @@ LSX_ and lsx_ symbols should not be used by libSoX-based applications. #include <limits.h> #include <stdarg.h> #include <stddef.h> +#include <stdint.h> #if defined(__cplusplus) extern "C" { @@ -458,13 +459,7 @@ typedef long long sox_int64_t; Client API: Unsigned 64-bit type. Typically defined as unsigned long or unsigned long long. */ -#if ULONG_MAX==0xffffffffffffffff -typedef unsigned long sox_uint64_t; -#elif defined(_MSC_VER) -typedef unsigned __int64 sox_uint64_t; -#else -typedef unsigned long long sox_uint64_t; -#endif +typedef uint64_t sox_uint64_t; #ifndef _DOXYGEN_ lsx_static_assert(sizeof(sox_int8_t)==1, sox_int8_size);
My interpretation is that sox.h (which is public API and thus should be changed carefully) intends to use uint64_t even on systems that don't have stdint.h. That is why it contains its own uint64_t typedef and detection macro. On macos we have stdint.h so we can simplify this.
comment:9 Changed 3 days ago by jacobvosmaer (Jacob Vosmaer)
If we don't want to include stdint.h in sox.h, which does constitute a user-visible change, we could do typedef unsigned long long sox_uint64_t;
in sox.h.
Build log