rustc generates a shared object for binaries

[CohenArthur]

When building a simple binary executable (tests/binary_project), cargo build && readelf -h target/debug/binary_project produces the following output:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x6760
  Start of program headers:          64 (bytes into file)
  Start of section headers:          3351096 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         14
  Size of section headers:           64 (bytes)
  Number of section headers:         42
  Section header string table index: 41

Meaning that the produced binary is an executable shared object file. This is fine, but isn't what gccrs currently does.

I wonder if this behavior is something that should be reproduced in gccrs? In that case I'll open up a corresponding issue. I am assuming that the answer is yes, since there are probably valid reasons for rustc to produce a shared object instead of a simple binary.

Therefore, I'm also wondering about the reasons behind that choice? Maybe @bjorn3 you know about this?

For reference, the binary currently produced by gccrs is of type EXEC

[bjorn3]

Rustc produces position independent executables by default. These have the DYN elf type.

By the way have you seen #34? If you follow my proposal, all code needs to be compiled as PIC on systems that support shared libraries anyway.

[CohenArthur]

Rustc produces position independent executables by default. These have the DYN elf type.

Great, thanks a lot. Then I'll simply pass -fPIC everywhere for now

By the way have you seen #34? If you follow my proposal, all code needs to be compiled as PIC on systems that support shared libraries anyway.

Yup, I have seen and read in details your proposal. Thanks a lot for taking the time and sorry for not having answered it, I was waiting for Philip to weigh in as I don't feel qualified enough haha

I think that for systems that do not support shared libraries we are still a ways off, as this is embedded territory (since all major OSes, no matter whether they are BSD-like, NT-like or Unix-like, have some sort of shared libraries) and gcc and cross compilation is super different from llvm based cross-compilation, and is therefore really far away imho. So I think that -fPIC everywhere should be fine.