sabotage-linux / netbsd-curses

libcurses and dependencies taken from netbsd and brought into a portable shape (at least to musl or glibc)
Other
147 stars 14 forks source link

Unable to build with gnu-efi (linker relocation fails) #45

Closed schreiberstein closed 3 years ago

schreiberstein commented 3 years ago

Hello!

I am interested in creating a UEFI application utilizing netbsd-curses. For this purpose, I attempted to build netbsd-curses against gnu-efi on a recent Debian GNU/Linux 11 testing/bullseye amd64 system. (gnu-efi is available as repository package)

However, after adjusting CFLAGS and LDFLAGS accordingly, I found myself unable to successfully link ANY shared library from netbsd-curses. All object files seem to compile flawlessly. I confirmed this by changing parts of the GNUmakefile and forcing some components off, etc.

All attempts to link terminate like this:

**cc -I. -I./libterminfo -DHAVE_WCHAR -DINSTALL_PREFIX=\"/usr\" -DINSTALL_PREFIX=\"/usr\" -I./tic -I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol -fno-stack-protector -fPIC -fshort-wchar -mno-red-zone -Wall -DEFI_FUNCTION_WRAPPER -O2 -c -o tic/hash.o tic/hash.c cc -nostdlib -znocombreloc -T /usr/lib/elf_x86_64_efi.lds -shared -Bsymbolic -L /usr/lib /usr/lib/crt0-efi-x86_64.o -lefi -lgnuefi tic/tic.o tic/cdbw.o tic/mi_vector_hash.o tic/compile.o tic/hash.o -o tic/tic /usr/bin/ld: /usr/lib/crt0-efi-x86_64.o: warning: relocation against ImageBase' in read-only section '.text' /usr/bin/ld: /usr/lib/crt0-efi-x86_64.o: relocation R_X86_64_PC32 against symbol 'ImageBase' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make: * [GNUmakefile:457: tic/tic] Error 1

I build using the following command:

!/bin/bash

EFIINCS="-I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol" LIB="/usr/lib" EFI_LDS="$LIB/elf_x86_64_efi.lds" EFI_CRT_OBJS="$LIB/crt0-efi-x86_64.o" LDFLAGS="-nostdlib -znocombreloc -T $EFI_LDS -shared -Bsymbolic -L $LIB $EFI_CRT_OBJS -lefi -lgnuefi" CFLAGS="$EFIINCS -fno-stack-protector -fPIC -fshort-wchar -mno-red-zone -Wall -DEFI_FUNCTION_WRAPPER -O2" make CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS" PREFIX=/usr all-dynamic

From what I can see (I also attempted to force CFLAGS and LDFLAGS into every "CC" line the makefile), all files are built with -fpic. The gnu-efi crt0-efi-x86_64.o was also built with -fpic (to be sure, I also rebuilt it myself).

Do you have any idea what might be causing this issue? If not, do you know an appropriate place where I could ask for help?

Thank you very much! Cheers,

schreiberstein

rofl0r commented 3 years ago

tbh i know next to nothing about EFI but you might want to check what's in the linker script used: /usr/lib/elf_x86_64_efi.lds. also i personally would probably try a static link for something like this. the fpic error you get seems to be caused by crt0-efi-x86_64.o (not part of ncurses) not being fpic but it's tried to being stuffed into a shared object, most likely because you have -shared in LDFLAGS which is wrong when linking an executable like tic.

schreiberstein commented 3 years ago

Thank you for your message. I will close this issue then. Since netbsd-curses is so portable, I suppose it will be easier to directly add its C files into my projects Makefile without gong through its own make process, which is what I will attempt next.

rofl0r commented 3 years ago

I suppose it will be easier to directly add its C files into my projects Makefile without gong through its own make process

why? you just need to get rid of the -shared when you build any executable. what you talk about here is called "vendoring" and it's a really bad idea, a thing that windows people that dont know better do. bad idea because you basically create an unmaintained fork.

schreiberstein commented 3 years ago

I suppose it will be easier to directly add its C files into my projects Makefile without gong through its own make process

why? you just need to get rid of the -shared when you build any executable. what you talk about here is called "vendoring" and it's a really bad idea, a thing that windows people that dont know better do. bad idea because you basically create an unmaintained fork.

You are right. Thanks for the advice. I will avoid this scenario.