Error in OSX compile


#1

In: gnuradio-core/src/lib/io/ :

g++ -DHAVE_CONFIG_H -I. -I…/…/…/… -DOMNITHREAD_POSIX=1 -
I…/…/…/…/omnithread -I…/…/…/…/gnuradio-core/src/lib/runtime -
I…/…/…/…/gnuradio-core/src/lib/general -I…/…/…/…/gnuradio-
core/src/lib/general -I…/…/…/…/gnuradio-core/src/lib/gengen -
I…/…/…/…/gnuradio-core/src/lib/gengen -I…/…/…/…/gnuradio-core/
src/lib/filter -I…/…/…/…/gnuradio-core/src/lib/filter -
I…/…/…/…/gnuradio-core/src/lib/reed-solomon -I…/…/…/…/
gnuradio-core/src/lib/io -I…/…/…/…/gnuradio-core/src/lib/g72x -
I…/…/…/…/gnuradio-core/src/lib/swig -I…/…/…/…/gnuradio-core/
src/lib/swig -I/opt/local/include -g -O2 -Wall -Woverloaded-virtual -
MT gr_udp_sink.lo -MD -MP -MF .deps/gr_udp_sink.Tpo -c
gr_udp_sink.cc -fno-common -DPIC -o .libs/gr_udp_sink.o
gr_udp_sink.cc: In member function ‘virtual int gr_udp_sink::work
(int, gr_vector_const_void_star&, gr_vector_void_star&)’:
gr_udp_sink.cc:168: error: no matching function for call to ‘min
(int&, long int)’
make[5]: *** [gr_udp_sink.lo] Error 1

This is a call to std::min, which from the C++ sources requires the
same type. Probably better to upgrade “d_payload_size” to a ssize_t
instead of downgrading the “long int” second argument. Does this
work correctly on other platforms? - MLD


#2

I…/…/…/…/omnithread -I…/…/…/…/gnuradio-core/src/lib/runtime -
gr_udp_sink.cc: In member function ‘virtual int gr_udp_sink::work
(int, gr_vector_const_void_star&, gr_vector_void_star&)’:
gr_udp_sink.cc:168: error: no matching function for call to ‘min
(int&, long int)’
make[5]: *** [gr_udp_sink.lo] Error 1

This is a call to std::min, which from the C++ sources requires the
same type. Probably better to upgrade “d_payload_size” to a ssize_t
instead of downgrading the “long int” second argument. Does this
work correctly on other platforms? - MLD

I had no problem with this (not even a warning) on my Linux
installation. I
think I have access to an OSX installation in my lab, so I’ll look into
this
first thing in the morning when I get to work.

I’m curious is this is a problem in NetBSD, too?

I really hate these platform-specific problems…

Tom


#3

gr_udp_sink.cc:168: error: no matching function for call to ‘min
(int&, long int)’
make[5]: *** [gr_udp_sink.lo] Error 1

I believe this is a 64-bit related problem.

int and long int are often different sizes on 64-bit machines.

I really hate these platform-specific problems…

Tom

Eric


#4

Tom - Yes, that will work just fine. That’s the initial fix I did
yesterday. Since it sounds like defining “ssize_t d_payload_size”
isn’t OK, then I’ll just delete my branch. Those were easy changes
anyway. Thanks for getting it fixed quickly; everyone with 64-bit
processor/OS/compiler will breathe easier :wink: - MLD


#5

Michael D. wrote:

-I…/…/…/…/gnuradio-core/src/lib/reed-solomon
long int)’
make[5]: *** [gr_udp_sink.lo] Error 1

This is a call to std::min, which from the C++ sources requires the
same type. Probably better to upgrade “d_payload_size” to a ssize_t
instead of downgrading the “long int” second argument. Does this work
correctly on other platforms? - MLD

Michael,

Sorry about this one, but try it now. I just did a check in to the trunk
since it was so simple. Although I might have been better to redefine
d_payload_size to a ssize_t, there are issues with that data type and
SWIG; it didn’t like me using ssize_t in the constructor argument.
Instead, it’s now being cast to a (ssize_t) in the std::min function.
That should be generic on any system.

Let me know if this works or not.

Tom


#6

anyway. Thanks for getting it fixed quickly; everyone with 64-bit
processor/OS/compiler will breathe easier :wink: - MLD

Good. I’ll try to keep an eye out for things of this nature in the
future
(although, to actually get to the root of the typedef of ssize_t is a
bit
obscured). I wish I had a 64-bit machine of my own to compile on and
test
before checkins to avoid these problems in the trunk. Maybe I’ll just
bug
you or Eric to do a test compile sometimes :slight_smile:

Tom


#7

Works for me too. :]


#8

On Fri, Feb 16, 2007 at 09:10:57AM -0500, Tom R. wrote:

Maybe I’ll just bug you or Eric to do a test compile sometimes :slight_smile:

Works for me :wink:

Eric