Win32 and gr-blocks/lib/stream_pdu_base.cc

GNU Radio
1

Since my previous message seems to be ignored, here is something
simpler for you to comment on.

In gr-blocks/lib/stream_pdu_base.cc, the read() and write() functions
are
used on sockets. This doesn’t work well on Windows as you’re probably
aware. A simple fix is to has something like this at the top of this
file:

#ifdef WIN32
#undef read
#undef write
#define read(sk,buf,len) ::recv (sk, (char*)(buf), len, 0)
#define write(sk,buf,len) ::send (sk, (const char*)(buf), len, 0)
#endif

I’m sure Boost have some better fix for this, but I don’t know
Boost.

–gv

2

On 10/05/2014 04:25 AM, Gisle V. wrote:

#undef write
#define read(sk,buf,len) ::recv (sk, (char*)(buf), len, 0)
#define write(sk,buf,len) ::send (sk, (const char*)(buf), len, 0)
#endif

I’m sure Boost have some better fix for this, but I don’t know
Boost.

The issue is that the stream_pdu_base file descriptor is both a network
socket for socket_pdu and tuntap handle for tuntap_pdu. Calling ::recv()
and ::send() would be a good cross platform solution for the socket
case, but im not sure if that will work for the tuntap (which is linux
specific anyway).

Ideally we could switch the code to call send/recv, and the tuntap would
continue working – this needs testing.

Your patch is pretty good too, because it doesnt interfere with existing
functionality, and the tuntap is ifdefed out on windows.

The best way to upstream patches seems to be through github. I recommend
creating a github pull request for this change, and some of the other
changes you mentioned in the previous email.

-josh

3

Josh B. wrote:

#undef read
#undef write
#define read(sk,buf,len) ::recv (sk, (char*)(buf), len, 0)
#define write(sk,buf,len) ::send (sk, (const char*)(buf), len, 0)
#endif

…

Ideally we could switch the code to call send/recv, and the tuntap would
continue working – this needs testing.

Your patch is pretty good too, because it doesnt interfere with existing
functionality, and the tuntap is ifdefed out on windows.

Just a note on this (my almost 1 year old email). Seems there are no
Windows
users of GnuRadio that needs to play with sockets.

I did a “git pull” just now and saw to my dismay that this issue (with
using
read() + write() on sockets) is still present. According to github, the
last
change of this (relevant to Winsock) file was on 5 March 2013!

–gv

4

Martin B. wrote:

I’m not sure what you’re saying/asking here.

Maybe the original makes it clear:
[Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc

It’s true we don’t have a
lot of Windows developers, and if you’re willing to take on this issue,
it would be appreciated.

Trying to build Volk using MSC seems impossible now, so the issue
will have to wait. E.g. on volk:
volk_cpu.c(85): error C3861: ‘__cpuid_count’: identifier not found

Seems to GNU-C is required now (MingW/gcc has this function. MSVC does
not). Is this intentional or just another miss? If the former, why the
unfriendliness towards MSVC?

–
–gv

5

On 01.09.2015 05:31, Gisle V. wrote:

Just a note on this (my almost 1 year old email). Seems there are no
Windows
users of GnuRadio that needs to play with sockets.

I did a “git pull” just now and saw to my dismay that this issue (with
using
read() + write() on sockets) is still present. According to github, the
last
change of this (relevant to Winsock) file was on 5 March 2013!

Hey Gisle,

I’m not sure what you’re saying/asking here. It’s true we don’t have a
lot of Windows developers, and if you’re willing to take on this issue,
it would be appreciated.

Cheers,
Martin

6

Hi Gisle,

rest assured, there’s no unfriendliness towards MSVC – it’s just that
we’re currently really lacking people who have MSVC or even just Windows
experience, and hence, problems like these can go unnoticed.
Again, that’s not a sign of anyone disliking MSVC, it’s just that it’s
been a while since most of us did development under Windows. Also, VOLK
is mainly hand-optimized assembler, so I really can’t blame anyone who
didn’t have acute access to MSVC to try with that; that being said, I’d
actually like to see more reports/wiki pages on how to successfully
build GNU Radio under Windows – I think there was a thread lately, but
I can’t seem to find it.

GCC shouldn’t be the only compiler supported, seeing as clang is
probably used on OS X, if I’m not mistaken.

So, to illustrate this:

the read() and write() functions are used on sockets. This doesn’t
work well on Windows as you’re probably aware
Nope, at least I wasn’t aware of any of that; that sounds strange to me,
because that’s nothing you’d expect on a system with a Unixoid API
(which WinNT had, I thought).

I like your fix, but: I also find it scary. I’d rather go ahead and try
whether using send/recv on all platforms would work, too.

Best regards,
Marcus