Re: [Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc
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 On 01.09.2015 23:07, Gisle Vanem wrote: > Martin Braun wrote: > >> I'm not sure what you're saying/asking here. > > Maybe the original makes it clear: > > https://lists.gnu.org/archive/html/discuss-gnuradio/2014-10/msg00044.html > >> 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? > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc
Martin Braun wrote: I'm not sure what you're saying/asking here. Maybe the original makes it clear: https://lists.gnu.org/archive/html/discuss-gnuradio/2014-10/msg00044.html 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc
Josh Blum wrote: On 10/05/2014 04:25 AM, Gisle Vanem wrote: 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 ... 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc
On 01.09.2015 05:31, Gisle Vanem 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc
On 10/05/2014 04:25 AM, Gisle Vanem wrote: 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. 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 --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio