BatchDrake/suscan

build error: conflicting types for ‘suscan_object_get_field_float’

Closed this issue · 6 comments

$ sigutils_CFLAGS="-I$(pwd)/../sigutils" sigutils_LIBS="-L$(pwd)/../sigutils/sigutils/.libs" ./configure

$ make
make  all-recursive
make[1]: Entering directory '/sources/suscan'
Making all in util
make[2]: Entering directory '/sources/suscan/util'
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  -I. -I  -I. -ggdb -I/sources/suscan/../sigutils -I/usr/include/libxml2 -DPKGDATADIR=\"/usr/local/share/suscan\"   -MT libutil_la-object.lo -MD -MP -MF .deps/libutil_la-object.Tpo -c -o libutil_la-object.lo `test -f 'object.c' || echo './'`object.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I. -I -I. -ggdb -I/sources/suscan/../sigutils -I/usr/include/libxml2 -DPKGDATADIR=\"/usr/local/share/suscan\" -MT libutil_la-object.lo -MD -MP -MF .deps/libutil_la-object.Tpo -c object.c  -fPIC -DPIC -o .libs/libutil_la-object.o
object.c:306:1: error: conflicting types for ‘suscan_object_get_field_float’
  306 | suscan_object_get_field_float(
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from object.c:26:
object.h:110:9: note: previous declaration of ‘suscan_object_get_field_float’ was here
  110 | SUFLOAT suscan_object_get_field_float(
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
object.c: At top level:
object.c:388:1: error: conflicting types for ‘suscan_object_set_field_float’
  388 | suscan_object_set_field_float(
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from object.c:26:
object.h:125:8: note: previous declaration of ‘suscan_object_set_field_float’ was here
  125 | SUBOOL suscan_object_set_field_float(
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [Makefile:417: libutil_la-object.lo] Error 1
make[2]: Leaving directory '/sources/suscan/util'
make[1]: *** [Makefile:544: all-recursive] Error 1
make[1]: Leaving directory '/sources/suscan'
make: *** [Makefile:408: all] Error 2

Okay, this is odd. It's like you have mixed versions of object.c and object.h. What branch are you trying to build? Could you please copy lines 305-310 of util/object.c and 110-114 of util/object.h here?

b610aef

// util/object.c
SUFLOAT
suscan_object_get_field_float(
    const suscan_object_t *object,
    const char *name,
    float dfl)

// util/object.h
SUFLOAT suscan_object_get_field_float(
    const suscan_object_t *object,
    const char *name,
    SUFLOAT dfl);

Wow, this was a big one, thank you! Could you pull from branch hotfix/inconsistent-prototypes and try again?

Btw, this raises another question nonetheless, which is why SUFLOAT could possibly be different from float. This should only happen if the macro _SU_SINGLE_PRECISION is not defined, and that would definitely be a build system bug. What OS are you using for the build? What is your compiler version? Could you paste the last lines of make's output immediately before the error?

Thank you very much again!

/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  -I. -I  -I. -ggdb -I/home/yug/comp/sources/rtl-sdr/suscan/../sigutils -I/usr/include/libxml2 -DPKGDATADIR=\"/usr/local/share/suscan\"   -MT libutil_la-object.lo -MD -MP -MF .deps/libutil_la-object.Tpo -c -o libutil_la-object.lo `test -f 'object.c' || echo './'`object.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I. -I -I. -ggdb -I/home/yug/comp/sources/rtl-sdr/suscan/../sigutils -I/usr/include/libxml2 -DPKGDATADIR=\"/usr/local/share/suscan\" -MT libutil_la-object.lo -MD -MP -MF .deps/libutil_la-object.Tpo -c object.c  -fPIC -DPIC -o .libs/libutil_la-object.o
object.c:388:1: error: conflicting types for ‘suscan_object_set_field_float’
  388 | suscan_object_set_field_float(
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from object.c:26:
object.h:125:8: note: previous declaration of ‘suscan_object_set_field_float’ was here
  125 | SUBOOL suscan_object_set_field_float(
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(seems that suscan_object_set_field_float got hit)
After fixing this one I can compile further but linking fails with undefined reference to su_logprintf`

This one is probably related to the sigutils_LIBS variable. (As you noticed, I want to use my local/uninstalled copy of sigutils to avoid cluttering my /usr/loca/lib and thus the CFLAGS/LiBS tweaks attempts)
Strange, since my config.log shows sigutils_LIBS='-L/home/user/<blabla>/suscan/../sigutils/sigutils/.libs' which does exist.

Alright, that's a different story then 😁. Have in mind that compiling against sigutils is not only about the libraries and the headers, but the appropriate compiler command line (which contains macro definitions too). This is achieved through pkg-config, which reads the file sigutils.pc which, in turn, is generated during sigutils build and installed somewhere in your system.

In this case, I suggest you do the following instead parting from a fresh unmodified clone of both sigutils and suscan (which I never did so far, so your feedback would be extremely appreciated):

  1. Create a directory used for installation somewhere in your home directory, and save the full path in an environment variable (e.g. SUSTUFF):
% export SUSTUFF=~/su-stuff
% mkdir $SUSTUFF
  1. Build sigutils, passing your destination directory as prefix, and then run make install (important: do it as regular user!).
% cd sigutils
% ./configure --prefix=$SUSTUFF
% make
% make install 

At this point, if you run ls $SUSTUFF you should see the following directories, which are what the sigutils installation consists of:

% ls $SUSTUFF
bin/  include/  lib/

3.Build suscan. This time, before calling ./configure --prefix=$SUSTUFF, you must tell pkg-config where is the new .pc file directory. This is achieved through PKG_CONFIG_PATH. Again, after build, remember to run make install as non-root:

% export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$SUSTUFF/lib/pkgconfig
% cd suscan
% ./configure --prefix=$SUSTUFF
% make
% make install
  1. You can test your installation by running:
% export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SUSTUFF/lib
% $SUSTUFF/bin/suscan

If you are attempting to build SuWidgets and SigDigger (which I guess is your final goal), I think you may need to modify a couple of files. Tell me if you reach step 4 successfully and then we will see what is the best approach from that point.

I've just succeeded in installing SigDigger in my home directory and yes, you will definitely need to make some changes in a couple of files. However, although SigDigger seemed to work just fine, it may be retrieving files from my existing system-wide installation. Once you get to compile SigDigger, tell me if you experience any issues (I expect things like missing spectrum palettes, autogains, etc) and I'll fix them ASAP.

Thanks!