ELF64 Shared Libraries

[mariuszp]

I was looking at the ELF64 specification in hope to find out how to dynamically link with a shared library, i understand there is a "dynamic" program header, but it seems like GCC is omitting it from the libc.so when building it (there are no program headers at all). And I've found multiple versions of the ELF64 spec on the internet and cannot seem to find which one is the most accurate.

Does anyone have a good explanation or some sample code to do this?

[Icee]

I was looking at the ELF64 specification in hope to find out how to dynamically link with a shared library, i understand there is a "dynamic" program header, but it seems like GCC is omitting it from the libc.so when building it (there are no program headers at all). And I've found multiple versions of the ELF64 spec on the internet and cannot seem to find which one is the most accurate.

Does anyone have a good explanation or some sample code to do this?

If there are no program headers, this usually means that you are looking at an object file which is subject to additional (compile-time, not run-time) linking before a program or a shared library is built. Probably you are just inspecting the wrong file.

Here's a sample output for /lib/libc.so.6:

Code: Select all

[12:27] icee@earth ~ $ readelf -l /lib/libc.so.6

Elf file type is DYN (Shared object file)
Entry point 0x16d20
There are 10 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00000034 0x00000034 0x00140 0x00140 R E 0x4
  INTERP         0x12bc10 0x0012bc10 0x0012bc10 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x00000000 0x00000000 0x141a48 0x141a48 R E 0x1000
  LOAD           0x1421c0 0x001431c0 0x001431c0 0x027bc 0x057a8 RW  0x1000
  DYNAMIC        0x143d7c 0x00144d7c 0x00144d7c 0x000f0 0x000f0 RW  0x4
  NOTE           0x000174 0x00000174 0x00000174 0x00044 0x00044 R   0x4
  TLS            0x1421c0 0x001431c0 0x001431c0 0x00008 0x00040 R   0x4
  GNU_EH_FRAME   0x12bc24 0x0012bc24 0x0012bc24 0x0319c 0x0319c R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
  GNU_RELRO      0x1421c0 0x001431c0 0x001431c0 0x01e40 0x01e40 R   0x1

The dynamic section can be dumped with "readelf -d <FILESPEC>". The base ELF64 spec is this one, however you should also consider machine-specific supplements for your targets.

[mariuszp]

When I build a C library using my OS cross-compiler, it is marked as DYN but has no program headers or dynamic section. The LINK_SPEC in GCC code in glidix.h is:

Code: Select all

#undef LINK_SPEC
#define LINK_SPEC "\
  %{shared:-shared} \
  %{!shared: \
    %{!static: \
      %{rdynamic:-export-dynamic} \
      -dynamic-linker /lib/glidixld.so} \
      %{static:-static}}"

Without this LINK_SPEC it simply marks the library as executable, ignoring the -shared flag, but linux.h does not seem to have LINK_SPEC at all...

Is anything wrong here?

[jnc100]

Does passing '-Wl,-shared' rather than '-shared' to gcc work?

Regards,
John.

[mariuszp]

Does passing '-Wl,-shared' rather than '-shared' to gcc work?

Regards,
John.

Nope, same effect. And passing -v tells me that -shared is passed to the linker anyway. And it does mark the output as DYN, but without program headers, or a dynamic section, and also no symbol table. libc.so is actually made like this:

Code: Select all

x86_64-glidix-gcc -shared -o out/lib/libc.so out/lib/libc.a

Could this be a reason?

[jnc100]

Linking a static library with the '-shared' option to try and create a shared library is not the way to do it. You should recompile the object files from source with the -fPIC option and then link them together with -shared to create the shared library.

If you get errors then try with a standard x86_64-elf-gcc first to see if it is an error with your port.

Regards,
John.

[mariuszp]

Oops, looks like creating it from a static library was the problem.