[cfarm-users] having a bit of trouble with getting into the new netbsd and freebsd virtual machines

[CM Graff]

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 <cm0graff at 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 at 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 at lists.tetaneutral.net
>> https://lists.tetaneutral.net/listinfo/cfarm-users
>>
>