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]

[tthoma24 (Teddy Thomas)]

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....

[tthoma24 (Teddy Thomas)]

Build log

[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.

[MaurizioLoreti]

Me too, same error; MacPorts 2.10.2, Sequoia 15.0.1.

[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.

[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.

[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.

[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.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #71289.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

This problem might be what ​this sox_ng commit is fixing.

Not sure what happened since I found that commit four weeks ago but it does not exist anymore.

Instead I've now found ​this commit which looks plausibly relevant, specifically the part that changes the type of the offset parameter in various functions from uint64_t to sox_uint64_t.

Replying to jacobvosmaer:

@@ -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);

I'd be reluctant to change this code, since even sox_ng still keeps this code.

[ryandesign (Ryan Carsten Schmidt)]

In bb21bbe61580e3a811bac985e3d617ac6e9a44cc/macports-ports (master):

sox: Fix incompatible function pointer types

Closes: #70720

[wwalexander (William Alexander)]

Still getting this error after a clean and selfupdate.

[MaurizioLoreti]

Replying to wwalexander:

Still getting this error after a clean and selfupdate.

Me too. Same error.

[ryandesign (Ryan Carsten Schmidt)]

Please attach the new main.log file.

[MaurizioLoreti]

Well, today 'sudo port install sox' succeeded. That command installed libgsm @1.0.22_0 as a dependency, then sox @14.4.2_5. Thank you for your perseverance, and your help.