On Fri, 16 Jun 2017, Adam Steen wrote:
> I am attempting to port Solo5 to OpenBSD (Virtio only), I think i have
> the kernel and test_hello compiling but when it comes to linking
> test_hello i get the following error.
>
> /home/asteen/devl/solo5/kernel/virtio/solo5.o: relocation R_X86_64_32
> against 'a local symbol' can not be used when making a shared object;
> recompile with -fPIC [1]
...
> clang -fPIC -nostdlibinc -ffreestanding -mno-red-zone -isystem
> /home/asteen/devl/solo5/include-host -std=gnu99 -Wall -Wextra -Werror
> -O2 -g -I/home/asteen/devl/solo5/kernel -c test_hello.c -o
> test_hello.o
That part is okay.
> ld -T /home/asteen/devl/solo5/kernel/virtio/solo5.lds \
> -nostdlib -z max-page-size=0x1000 -static -o test_hello.virtio
> /home/asteen/devl/solo5/kernel/virtio/solo5.o test_hello.o
This part is not. Projects aiming for portability should build both
executable and shared libraries via the compiler driver ('clang', 'cc', or
'gcc') and *not* by invoking ld directly.
This is because the objects generated by the C compiler may depend on the
presence of symbols provided by objects or options supplied by the
compiler driver. That's true not just on OpenBSD but on Linux as well.
In this case, you've almost certainly hit the need for the __guard_local
symbol, which is provided by crtbeginS.o
(Note: crtbeginS.o itself needs another object supplied by the compiler
driver, so don't even _think_ of pulling it in manually!)
Philip Guenther
