Hey again everyone! I got into the NetBSD VM and am working on NetBSD support for hlibc. This is just a fairly naive trial run using the syscall numbers from freebsd's syscall.master. Something is a bit odd, as if NetBSD needs ELF or some type of linux emulation layer. Here is what I got:
gcc300$ ./usr/bin/compiler ../some.c cc = + exec gcc -fno-pie -fno-stack-protector -static '-D_GNU_SOURCE' '../some.c' -specs '/home/cgraff1/hlibc/usr/lib/gcc-wrap.specs' gcc300$ ./a.out -sh: Cannot execute ELF binary ./a.out I am not sure that we should contaminate the NetBSD VM with different compat layers. I can try doing a NetBSD "build.sh" within my /home and then rearrange the PATHs. Any suggestions? Thanks! Graff On 10/6/18, Olly Betts via cfarm-users <cfarm-users@lists.tetaneutral.net> wrote: > On Sat, Oct 06, 2018 at 04:04:52PM -0500, Segher Boessenkool wrote: >> On Sat, Oct 06, 2018 at 09:25:25PM +0100, Olly Betts via cfarm-users >> wrote: >> > gcc300$ getaddrinfo -f inet -t stream ::1 >> > stream inet tcp 192.168.66.50 0 >> >> $ route -n show >> >> tells you why this is. > > Thanks, but I'm failing to understand the explanation if it is there > (I'd actually even already tried that command). > > On Sat, Oct 06, 2018 at 03:14:12PM -0600, Assaf Gordon wrote: >> On 06/10/18 03:06 PM, Assaf Gordon wrote: >> > The physical server hosting the VMs is 192.168.66.50. > > OK, so it isn't just an arbitrary IPv4 address on the same network. > >> > The NetBSD VM is 192.168.66.202. >> > The public IP (184.68.105.38) machine forwards the TCP ports (e.g. 2400) >> > to the internal VMs. >> > >> > This seems pretty standard to me, but if there are possible >> > improvements to the VM's configuration I'm happy to try them. > > It sounds like an entirely reasonable configuration to me. > >> I should add that the physical server is a Debian 9 (stretch), >> using libvirt as the virtual machine infrastructure, >> and the networking is setup to "bridge" mode, as explained here: >> >> https://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29 >> >> Perhaps that is why, under certain circumstances, you get areply >> with the physical host IP (192.168.66.50) instead of the VM's IP. > > Perhaps, though it seems very odd that IPv6 addresses get resolved > with "-f inet" at all. E.g. on the FreeBSD VM (gcc303): > > $ getaddrinfo -f inet -t stream ::1 > getaddrinfo: Non-recoverable failure in name resolution > > And based on what I see in my code calling the getaddrinfo() function, > Linux fails with EAI_ADDRFAMILY and macOS with EAI_NONAME. > >> Hope this helps, > > Somewhat. I'm still not really understanding why this happens, but > it makes a certain amount of sense that it's the IP for the host the VM > networking is bridged to, and I can easily avoid trying to resolve IPv6 > addresses with AF_INET without knowing exactly what is happening here. > Mostly I'm just happier when I actually understand stuff. > > Cheers, > Olly > > P.S. Thanks very much for hosting these VMs. Having access to a > variety of platforms just an ssh away is really useful for debugging > portability issues. > _______________________________________________ > cfarm-users mailing list > cfarm-users@lists.tetaneutral.net > https://lists.tetaneutral.net/listinfo/cfarm-users > _______________________________________________ cfarm-users mailing list cfarm-users@lists.tetaneutral.net https://lists.tetaneutral.net/listinfo/cfarm-users
