Hey Everyone!! To follow up, I think that the problem is a bit more complex. I am guessing now that there is a Linux/ELF compat mechanism somewhere in the default compiler search path. I think for hlibc to work with NetBSD I'll have to research how this all works, or perhaps even specify a different binary format. Because I am redirecting the compiler search paths to only look for hlibc's libc.a, crt1.o, crtn.o and crti.o something is probably getting excluded. Open to suggestions, but I am starting to think this is not a system maintenance issue but something of a different nature having to do with various less used compiler invocations.
Thank you! Graff On 10/6/18, CM Graff <cm0gr...@gmail.com> wrote: > 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
