Forum: GNU Radio Error in OSX compile

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
821c1adf3f4be2f2aa6fbc89cce4c69a?d=identicon&s=25 Michael Dickens (Guest)
on 2007-02-14 23:46
(Received via mailing list)
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
8cc60441dc67b4e59421ebe95dc63c23?d=identicon&s=25 Tom Rondeau (Guest)
on 2007-02-15 04:18
(Received via mailing list)
> 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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-02-15 13:50
(Received via mailing list)
> > 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
8cc60441dc67b4e59421ebe95dc63c23?d=identicon&s=25 Tom Rondeau (Guest)
on 2007-02-16 03:36
(Received via mailing list)
Michael Dickens 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
821c1adf3f4be2f2aa6fbc89cce4c69a?d=identicon&s=25 Michael Dickens (Guest)
on 2007-02-16 03:41
(Received via mailing list)
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 ;) - MLD
8cc60441dc67b4e59421ebe95dc63c23?d=identicon&s=25 Tom Rondeau (Guest)
on 2007-02-16 15:11
(Received via mailing list)
> anyway.  Thanks for getting it fixed quickly; everyone with 64-bit
> processor/OS/compiler will breathe easier ;) - 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 :)

Tom
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-02-17 00:43
(Received via mailing list)
On Fri, Feb 16, 2007 at 09:10:57AM -0500, Tom Rondeau wrote:
>
> Maybe I'll just bug you or Eric to do a test compile sometimes :)
>

Works for me ;)

Eric
821c1adf3f4be2f2aa6fbc89cce4c69a?d=identicon&s=25 Michael Dickens (Guest)
on 2007-02-19 02:55
(Received via mailing list)
Works for me too. :]
This topic is locked and can not be replied to.