sipwise/rtpengine

Conflicting declarations for span_log_set_message_handler() and dtmf_rx_fillin()

dilyanpalauzov opened this issue · 3 comments

With most recent spandsp (commit e59ca8f), compiling fails with:

  • in lib/dtmf_rx_fillin-02.h the definition of INLINE void dtmf_rx_fillin(dtmf_rx_state_t *dsp, int n) { must be changed to INLINE int dtmf_rx_fillin(dtmf_rx_state_t *dsp, int n) {. The actual compiler error is reported at #1239 as second error.
Trying build with ../lib/spandsp_logging-01.h                                                                                           
make[3]: Entering directory '/git/voip/rtpengine/daemon'                                                                                
cc -g -Wall -Wextra -Wno-sign-compare -Wno-unused-parameter -Wstrict-prototypes -pthread -fno-strict-aliasing -std=c99 -I/usr/local/incl
ude/glib-2.0 -I/usr/local/lib64/glib-2.0/include -I/usr/local/include -pthread -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr
/local/lib64/glib-2.0/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -
I/usr/local/include -I/usr/local/include -I/usr/local/include -pthread -I/usr/local/include/json-glib-1.0 -I/usr/local/include -I/usr/lo
cal/include/glib-2.0 -I/usr/local/lib64/glib-2.0/include -I/usr/local/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/local/
include -I/usr/local/include -DWITH_IPTABLES_OPTION -I. -I../kernel-module/ -I../lib/ -I../include/ -D_GNU_SOURCE -I/usr/local/include -
I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include/opus -DWITH
_TRANSCODING -I/usr/local/mysql/include  -DHAVE_BCG729 -I/usr/local/include -DRTPENGINE_VERSION="\"git-master-cf51ccd7\""  -DHAVE_LIBSYS
TEMD  -rdynamic  spandsp_logging-test.c  -lm -ldl -L/usr/local/lib64 -lglib-2.0 -L/usr/local/lib64 -pthread -lgthread-2.0 -lglib-2.0 -L/
usr/local/lib -lz -L/usr/local/lib -lpcre -L/usr/local/lib64 -lcrypto -L/usr/local/lib64 -lssl -lcrypto -L/usr/local/lib -levent_pthread
s -levent -lpcap -L/usr/local/lib -lxmlrpc_client -lxmlrpc -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc_util -L/usr/local/lib -lxmlrpc -lx
mlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc_util -L/usr/local/lib -lxmlrpc_util -lhiredis -L/usr/local/lib64 -ljson-glib-1.0 -lgio-2.0 -lgob
ject-2.0 -lglib-2.0 -L/ -L/usr/local/lib -lwebsockets -lcap -L/usr/local/lib -lip4tc -lip6tc -L/usr/local/lib -lavcodec -L/usr/local/lib
 -lavformat -L/usr/local/lib -lavutil -L/usr/local/lib -lswresample -L/usr/local/lib -lavfilter -L/usr/local/lib -lspandsp -L/usr/local/
lib -lopus -L/usr/local/mysql/lib -lmysqlclient -lz -lm -latomic -lssl -lcrypto -L/usr/local/lib64 -lbcg729 -L/lib64 -lsystemd -o spands
p_logging-test                                                                                                                          
In file included from spandsp_logging-test.c:9:                                                                                         
spandsp_logging.h: In function ‘my_span_set_log’:                                                                                       
spandsp_logging.h:5:9: error: too few arguments to function ‘span_log_set_message_handler’                                              
    5 |         span_log_set_message_handler(ls, h);                                                                                    
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                            
In file included from spandsp_logging-test.c:7:                                                                                         
/usr/local/include/spandsp/logging.h:123:20: note: declared here                                                                        
  123 | SPAN_DECLARE(void) span_log_set_message_handler(logging_state_t *s, message_handler_func_t func, void *user_data);              
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                 
spandsp_logging.h: In function ‘my_span_mh’:
spandsp_logging.h:8:9: error: too few arguments to function ‘span_set_message_handler’
    8 |         span_set_message_handler(h);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/spandsp/logging.h:125:20: note: declared here
  125 | SPAN_DECLARE(void) span_set_message_handler(message_handler_func_t func, void *user_data);
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~
spandsp_logging-test.c: In function ‘main’:
spandsp_logging-test.c:18:29: warning: passing argument 2 of ‘my_span_set_log’ from incompatible pointer type [-Wincompatible-pointer-ty
pes]
   18 |         my_span_set_log(ls, logfunc);
      |                             ^~~~~~~
      |                             |
      |                             void (*)(int,  const char *)
spandsp_logging.h:4:73: note: expected ‘message_handler_func_t’ {aka ‘void (*)(void *, int,  const char *)’} but argument is of type ‘vo
id (*)(int,  const char *)’
    4 | INLINE void my_span_set_log(logging_state_t *ls, message_handler_func_t h) {
      |                                                  ~~~~~~~~~~~~~~~~~~~~~~~^
make[3]: *** [<builtin>: spandsp_logging-test] Error 1
make[3]: Leaving directory '/git/voip/rtpengine/daemon'
Failed build with ../lib/spandsp_logging-01.h
Trying build with ../lib/spandsp_logging-02.h

I think you're looking at the wrong reason for a build failure.

With SpanDSP from e59ca8f, compilation is expected to fail with spandsp_logging-01.h and expected to succeed with spandsp_logging-02.h, and the log excerpt you posted ends just before that file is tried. So you should see a success immediately following what you posted.

Similarly for dtmf_rx_fillin, compilation should succeed with dtmf_rx_fillin-01.h if that function is present and provided by SpanDSP, and should succeed with dtmf_rx_fillin-02.h if it's not present, in which case the return type doesn't matter.

Yes, but the build system nevertheless shows red errors, and that errors always need to be investigated.

Yes, but the build system nevertheless shows red errors, and that errors always need to be investigated.

Ok, that is a valid concern. I do agree that the errors from these build tests should be silenced unless the final result is an error.