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)

main.log (171.2 KB) - added by tthoma24 (Teddy Thomas) 2 months ago.
Build log

Download all attachments as: .zip

Change History (10)

Changed 2 months ago by tthoma24 (Teddy Thomas)

Attachment: main.log added

Build log

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 RCsox @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 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 in reply to:  6 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.

Note: See TracTickets for help on using tickets.