FreeBSD: Cannot compile due to unresolved import of: AF_NETLINK, AF_PACKET and accept4
Norbytus opened this issue · comments
Thanks for reproting.
As i don't have FreeBSD it is difficult for me to verify unix part of code.
It seems there is no AF_NETLINK & AF_PACEKT, but i find it strange that you do not have access to accept4 on freebsd as it should be available https://doc.rust-lang.org/libc/x86_64-unknown-freebsd/libc/fn.accept4.html
Most possibly AF_NETLINK & AF_PACKET will need be linux only flags and for accept4 i need to check libc version
Ok accept4 has been added recently to libc rust-lang/libc#546
When next version of libc will be out i'll pin my crate to it and for unresolved constants i'll make fix later on
I can test on FreeBSD and Linux, if you need
@Norbytus Could you please check that you can build with new libc 0.2.22
I also uploaded 0.2.1 version that bumped minimum required libc to this version.
Are these failing tests persistently failing?
I will need to investigate what's wrong with tests then.
It is especially strange to see error here https://github.com/DoumanAsh/lazy-socket.rs/blob/master/tests/socket.rs#L338 - maybe BSD implementation differs somehow from linux and we do not set non-blocking flag properly.
I did it tommorow.
@Alexander255 ping. I would appreciate some help with BSD sockets :)
Doing a quick read over socket_select_connect
it would appear as if FreeBSD does not consider a non-blocking connect to a localhost
TCP address and asynchronous operation and therefor immediately returns a success value. We currently assume, however, that a non-blocking connect will always return EINPROGRESS
.
It would be very useful to have a strace target/debug/deps/socket-9a271bcd0abf4f86
to confirm that that's indeed what's happening.
For the second error I believe @DoumanAsh has already fixed the problem in the mean time 😀
@Alexander255 That's what i suspected... Still i'm not sure should we have test that is trying to connect to some remote host instead
I add Norbytus@7c7f4d3 options for reuse addres and port, and run ktrace(strace) i get some time it's good some no.
And many people use fcntl for block stream in BSD
@DoumanAsh: I guess we could connect 8.8.8.8:53
or something. The test should print out a large warning on startup that its outcome depends on external servers and an active network connection, so that an appropriate "error message" (stdout output) is visible if the test fails.
@Norbytus: It's weird that adding SO_REUSEADDR
would change anything in this case, but either way doing that is not a fix.
With "It would be very useful to have a strace target/debug/deps/socket-9a271bcd0abf4f86
", I actually meant it would be useful to have the relevant strace/ktrace output. I have just assumed that something like strace (with somewhat different output) exists on all unices (even MSYS has a very lightweight implementation of this). So what I actually meant was:
- Please run
ktrace target/debug/deps/socket-9a271bcd0abf4f86
to get debugging information of the test (don't useRUST_BACKTRACE
environment variable through) - Run
kdump -dH
to parse the generated trace file - Look for the relevant
CALL connect(…)
line that tries to connect to 127.0.0.1:60006 and check whether it returns a success value or anEINPROGRESS
error (or copy the relevant lines)
@Alexander255 four 8 is google DNS, right? Hm... well connecting to google DNS seems to be more or less reliable. So i suppose we can go with it.
I'm not particularity happy about the choice either, but how many probably-reliable guaranteed-static-IPv4 TCP services do you know? Suggesting Google DNS was pretty much by default and is technically an abuse of their service. 🙂
@Norbytus I pushed update to use google DNS could you please try it out?
@Alexander255 Yeah, i understand. I just asked cuz i saw port 53 :)
I'm sorry. Only today had senn message from @DoumanAsh. So did pull. And it's ok. But time at time has error, but now on tcp and tcp6 test.
No problem. I think it is just github mentions are case sensitive and that's why you didn't see.
For tcp/tcp6 errors i think it is just how it is now. They are not exactly stable.
Anyway good that now it works on FreeBSD.