2

I am using nasm 64 to compile .S to .o and then create a shared library with gcc like this:

nasm -f elf64 source/strlen.S
nasm -f elf64 source/strchr.S
nasm -f elf64 source/memset.S
nasm -f elf64 source/strcspn.S
nasm -f elf64 source/rindex.S
nasm -f elf64 source/strpbrk.S
nasm -f elf64 source/strcmp.S
nasm -f elf64 source/strncmp.S
nasm -f elf64 source/strcasecmp.S
/usr/bin/gcc -shared ./source/strlen.o ./source/strchr.o ./source/memset.o ./source/strcspn.o ./source/rindex.o ./source/strpbrk.o ./source/strcmp.o ./source/strncmp.o ./source/strcasecmp.o -o libasm.so

source/rindex.S calls the fonction strlen which is in source/strlen.S The compilation line throw an error:

/usr/bin/ld: ./source/rindex.o: relocation R_X86_64_PC32 against symbol `strlen' can not be used when making a shared object; recompile with -fPIC

I could use -fPIC option with gcc when compiling the .S but I am using nasm and I don't find the equivalent option.

Does someone know how I can avoid this issue ?

Thanks in advance.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
nsvir
  • 8,781
  • 10
  • 32
  • 47
  • You are the "compiler" (generating asm by hand). It's up to you to avoid 32-bit absolute addresses (as in modern PIE executables: [32-bit absolute addresses no longer allowed in x86-64 Linux?](https://stackoverflow.com/q/43367427)). And if you want to respect symbol-interposition stuff you need to do that manually as well, going through the PLT or GOT even for your own static storage, unless you want to treat it like ELF visibility = hidden. – Peter Cordes Nov 23 '21 at 06:02

1 Answers1

3

You need to make sure you are writing position independent code. You might find the DEFAULT REL and the REL keyword itself helpful.

Jester
  • 56,577
  • 4
  • 81
  • 125