Fix GHC ticket 2615 (linker scripts in .so files)

[Duncan Coutts]

On Mon, 2009-11-30 at 22:49 -0800, Howard B. Golden wrote:
> Mon Nov 30 22:12:34 PST 2009  howard_b_golden at yahoo.com
>   * Fix GHC ticket 2615 (linker scripts in .so files)
>   This patch only applies to systems that use ELF format files.
>   The patch modifies the addDLL function so that it recognizes
>   "invalid ELF header" errors. If these occur, the file that was opened
>   is scanned for a linker script GROUP ( ... ) directive. If found,
>   the first file inside the GROUP ( ... ) will be sent to dlopen.
>   Any errors reported by dlopen then will be reported  to the caller.

First of all. I'm happy enough with this approach as an interim measure.
We know it will not work in all cases, eg it cannot cope with:

GROUP ( /lib64/libpthread.so.0 /usr/lib64/libpthread_nonshared.a )

because we cannot obtain any of the symbols from the nonshared version.

For the funny Gentoo ld script hackery like /usr/lib64/libpcre.so:

GROUP ( /lib64/libpcre.so.0 )

it should work. However I think we could do better. We talked to one of
the Gentoo hackers and he pointed out that really we ought to be
dlopen'ing /lib64/libpcre.so.0 in the first place. A compiled installed
package ought to be referring to a specific SONAME including the .0 or
whatever version number. That could be dlopened fine.

What remains is to work out a way to resolve -lpthread
to /lib64/libpcre.so.0 which could be recorded in the package
description. Of course this is exactly what the native system linker
does.

So another way to look at this is that this will all go away when we
build Haskell packages for ghci as shared libs using the native linker.

Duncan