error when compiling for x86_64-pc-windows-gnu #3
Comments
|
I've added a new branch, I also incorrectly assumed that nix and other things flagged in your build would still provide those symbols, even if their implementations were effectively just generating errors. It seems to build in a limited cross-compilation environment here, but I haven't used Windows in over two decades, so I'm afraid I don't have any means of testing it myself. |
|
thanks for looking into this! I'll happily test. client: p.s. I tried cross compiling for aarch64 (target |
|
Can you re-run this with I suspect the block is happening at rperf/src/protocol/communication.rs Line 45 in 14d3826 write_all() is supposed to take care of overflows. So it might be happening somewhere else.
|
|
server: client: |
|
I'll hopefully be able to do some testing directly against M1/M2 hardware later this year, running native Mac OS, but for now, I'm just trusting that nix provides the facilities I read in its documentation. aarch64 for Linux should work, though: we do a lot of testing with SBCs, even down to some 8-bit controllers. I'll need to know more about what you mean by "brick walls". |
|
Yeah... sending 176 bytes really shouldn't be a problem with the socket in the state I expect it's in. But it looks like mio's implementation changed since 0.6 (in a manner that may have been later retconned by changing the function's name) and now it expects the stream to already be in non-blocking mode, rather than performing that conversion itself. It expects everything to be non-blocking, actually. Creating another branch off of the Windows one to build this, though I'm afraid I'm working on a number of other things today, so I can't promise super-quick responses. |
|
Ah, it's not that mio's interface changed within 0.6, it's that it behaves very differently on Windows. And mio 0.7+ removed set_keepalive(), which was the only reason I had introduced it in the first place. Learning what I can. |
I don't think it's rperf related, just probably cross compilation rust stuff (missing linker libs, things like that) - I've already burnt a few hours on it today, it's not exactly a well documented procedure (macos m1 targeting |
it's fine, surely nothing urgent about this Windows build, any effort is appreciated |
|
I've excised mio in the I'm trying to figure out how to minimise its impact, but for now, you should be able to build that for Windows to see if it works. |
|
I ended up putting bits of mio back in place, but it should all be working now. Possibly a little more accurate than before, though on the order of microseconds, nothing too significant. |
|
tested with |
|
This morning, I observed a Windows build linked through cross-compilation from Linux (same process you were using) succeed as a traffic-sending client without issue, so the "operation would block" issue may be something configuration or policy-based (a firewall, perhaps). It's possible the previous implementation would have worked, too. However, there is a problem when receiving traffic on Windows: only the first interval (one second) of traffic gets through with TCP and nothing with UDP, seemingly because the sender assesses a timeout, concludes the receiver isn't present, and gives up. I'll look into this when I have time, but it's a lot less obvious. I think I already have access to all the data I need, though (trace-level logs, packet-captures). As for aarch64/Linux, I'm still able to build without issue (Debian host), but because there's a dependence on dynamic linking (libc specifically), even if I felt comfortable providing precompiled binaries (and you'd feel comfortable accepting them), there's a high chance of a mismatch, so it's probably best to leave resolving the conflict to your own build environment (maybe use a VM on your M1 if you want to build with a native instruction-set), to avoid desync. |
|
interesting, I just (cross) compiled for macos, linux and it works between then on my x86 openwrt machine and m1 mac. regarding the aarch64, I get it, it's ok. I'll try cross |
|
Windows should now be able to receive UDP; still working on TCP. I may have also implemented a working handler for the would-block case you're experiencing, though nobody I've asked to help me test has reported it themselves. |
|
TCP reception should now work, too. Aside from being able to configure TCP keepalive and rend/receive-buffers, there should be functional parity between POSIX and Windows. If this checks out, I'll merge things and increase the version-number. |
|
since the windows build is running as client, I'm not really sure what could be blocking. |
|
Well, it was in a state where it wouldn't compile for Windows and I did need to rework time-accounting to make it deal with Microsoft's system clock semantics, so the issue definitely has merit. I'll hopefully be able to see it running on more Windows systems on Monday (I'm in Western Canada, so it's about 3am on Saturday now), and maybe one of them will stall so I can get a live testing candidate. For whatever it's worth, the Windows environment where it was observed to be working is Windows 10, x64, with very little in the way of additional security. I don't suppose Windows has any facilities like rperf/src/protocol/communication.rs Line 65 in cf01ff4 WouldBlock.
|
|
I don't know anything about p.s. can you provide the Windows test binary that worked for you, or for anyone you gave it to? or I can provide the .exe that I built, and maybe you can test that one, just to eliminate cross compilation shenanigans |
|
It's temporarily available in [pre-stable-binary link redacted]. md5sum (XZ compressed): |
|
your binary works! client AND server (linux <> windows, simple testing). you can take it down as far as I'm concerned.. |
|
My build environment is Debian Trixie (Testing) All I'm doing is Prior steps included I recall that |
|
I'm on macOS 13, something in the Apple+rust, aarch64 -> x86, is probably not mature enough. |
|
I'm making arrangements to buy a Mac to figure this out (I have other things to port to ARM and could use the rough edges of Asahi to learn anyway), though it may take a couple of weeks before I have one available. |
|
I also considered Ashai linux on my m1, but it's got a way to go.. no external monitors is a huge problem for me. |
|
I've only been looking at Asahi for the past week (I have an entire Debian-based operating system to explore porting to ARM in general, not specifically to Apple Silicon, but just at a scale where I need to be able to rebuild binaries and things at decent speeds, without cross-compilation surprises), but it looks sufficient for my needs. I'm going to wait to see if M3 minis are part of the Apple announcement on Tuesday, then make a decision from there, but it's going to happen in some capacity, both for work (like the OS) and projects I maintain outside of work, like this. Kinda sucks that ARM is still so bound to U-BOOT and board-specific bring-up processes that Apple is the best option for a general-purpose dev-and-build system right now. I'd really love to just be able to put some reasonably specced mITX-like build together. Although, on that note, how much memory do you usually see your system watermark at when doing any sort of compilation task? |
|
my code is backend JS, so no much compilation going on here :) |
|
Tried in User@DESKTOP-HPEE9O3 UCRT64 ~/rperf
$ ./target/release/rperf.exe -s
[2024-01-19T00:33:32Z INFO rperf::server] server listening on 0.0.0.0:5199
[2024-01-19T00:34:26Z INFO rperf::server] connection from 127.0.0.1:52004
[2024-01-19T00:34:26Z ERROR rperf::server] error in client-handler: connection lost
[2024-01-19T00:34:26Z INFO rperf::server] 127.0.0.1:52004 disconnectedUser@DESKTOP-HPEE9O3 UCRT64 ~/rperf
$ ./target/release/rperf.exe -c 127.0.0.1 -p 5199
[2024-01-19T00:34:26Z INFO rperf::client] connecting to server at 127.0.0.1:5199...
[2024-01-19T00:34:26Z INFO rperf::client] connected to server
[2024-01-19T00:34:26Z ERROR rperf] unable to run client: operation would block |
|
I'm expecting to merge a PR in the next day or two that has been tested on Windows, though it's largely the same solution as in the Can I ask which branch you used that led to that problem? |
|
@flan |
|
|
|
Also have the "unable to run client: operation would block". with cfg_if branch on cross compiled for windows. That is the result of: send() There is something wrong with the non-blocking socket that trow this error on windows: "would block". I have play around with polling the state before sending and notice that just polling fixed it. I'm not a programmer by trade, I leave it here and hopfully someone will be able to fixed it properly. pub fn send(stream:&mut TcpStream, message:&serde_json::Value) -> BoxResult<()> { } |
hi and thanks for rperf.
it is mentioned in the readme that
rperf should build and work on all major platforms, though its development and usage focus is on Linux-based systems, so that is where it will be most feature-complete.trying to switch from iperf to rperf, I need some binaries for Windows and Linux aarch64.
compiling for Windows fails with:
it seems that there are some dependencies on *nix tcp/udp
The text was updated successfully, but these errors were encountered: