hello.oに対して、libc.aではなくてlibc.soの方をリンクさせようと、"-lc"にしてみる。

 ld \
  /usr/lib/crt1.o \
  /usr/lib/crti.o \
  hello.o \
  `gcc -print-libgcc-file-name` \
  `gcc -print-file-name=libgcc_eh.a` \
  /usr/lib/crtn.o \
  -lc

これで生成されたa.outを実行しようとすると、
 $ ./a.out
 -bash: ./a.out: /usr/lib/libc.so.1: bad ELF interpreter: \
 そのようなファイルやディレクトリはありません
何故かというと
 $ readelf -l a.out
 
 Elf file type is EXEC (Executable file)
 Entry point 0x80482b0
 There are 7 program headers, starting at offset 52
 
 Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
   PHDR           0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
   INTERP         0x000114 0x08048114 0x08048114 0x00013 0x00013 R   0x1
       [Requesting program interpreter: /usr/lib/libc.so.1]
・・・ということで動的リンカの部分が"ld-linux.so"になってなかったから。

ここまでは良い。まぁ納得できる。でも、次が動くのは何で？
 $ /lib/ld-linux.so.2 ./a.out
 Hello, World
 $ echo $?
 123
"ld-linux.so.2"って実行可能なのか？だって、fileコマンドで見てみたら
 $ file /lib/ld-linux.so.2
 /lib/ld-linux.so.2: symbolic link to `ld-2.5.so'
 $ file /lib/ld-2.5.so
 /lib/ld-2.5.so: ELF 32-bit LSB shared object, \
      Intel 80386, version 1 (SYSV), not stripped
ってなってる。共有オブジェクトのように見えるが、コマンドラインからも実行可能なのか？どういう構造になってるんだろう・・・。

謎が多いなあ・・・。

他にも謎なのが、"-fPIC"と"-shared"が分かれている件。"-shared"が共有オブジェクトのためのオプションなのは分かるが、なんで"-fPIC"で位置独立コードを生成するようわざわざ指定する必要があるんだろう？わざわざ分けているということは・・・
位置独立コードだけど実行可能なファイルとか、位置独立でないけど共有オブジェクトなファイルとかがあり得る、と言う事だろうか・・・。
→試しに"-v"で途中経過を見てみたら、"-fPIC"がアセンブラコードの生成時に "cc1" に渡されている。"-shared"の方は "collect2" の方に渡されている。