[cfarm-users] having a bit of trouble with getting into the new netbsd and freebsd virtual machines
cm0graff at gmail.com
Sun Oct 7 06:36:25 CEST 2018
Once again hello everyone!
Assaf, I think that upgrading the NetBSD box to version 8 should not
be a terrible concern, at least it's not important to me. In my
opinion it may lead to a huge time investment and potential breakage.
In my opinion it might be easier to just start a new virtual machine
running NetBSD 8 when that time comes around and simply just keep
supplying security fixes for the NetBSD 7 box.
Regardless, it's up to you and everyone else of course. I just don't
want you spending lots of time on my behalf.
Thank you ! :)
On 10/6/18, CM Graff <cm0graff at gmail.com> wrote:
> Hey Assaf and everyone!
> I did discover a few things.
> gcc300$ echo "int x = 0;" > example.c
> gcc300$ cc --freestanding -nostdlib -static example.c
> ld: warning: cannot find entry symbol _start; defaulting to
> gcc300$ ./a.out
> -sh: Cannot execute ELF binary ./a.out
> Making this simple freestanding binary results in the same issue.
> When doing the same on my linux box, the a.out runs and the binary
> simply segfaults (but does run!).
> I did try the new clang package and it results in the same issue.
> Thank you for installing that Assaf! It will come in handy quite soon.
> I'll take some of these questions to the netbsd developers and try to
> get to the bottom of this.
> Thanks again!
> On 10/6/18, Assaf Gordon <assafgordon at gmail.com> wrote:
>> Hello Graff,
>> On 06/10/18 09:02 PM, CM Graff via cfarm-users wrote:
>>> 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.
>> I know very little about the above, but note that:
>> gcc300 is NetBSD 7.1 - not yet upgraded to NetBSD 8.0.
>> Not sure if there is a big difference.
>> I do plan to upgrade in the near future.
>> I've just installed clang-5.0.2 on gcc300,
>> perhaps using it instead of the (very old) gcc
>> would make things easier to troubleshoot.
>> - assaf
More information about the cfarm-users