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

[Simon Marlow]

On 03/12/2009 00:38, Howard B. Golden wrote:
> Hi Duncan,
>
> On Wednesday December 2, 2009, Duncan Coutts wrote:
>> 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.
>
> I agree that it won't do this.
>
>> 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.
>
> I know there was discussion of replacing Linker.c with a call to the
> native system linker. This seems to me to be the way to go. However, I
> don't know what monsters might lurk on that path.
>
>> 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.
>
> When is this change planned to occur? If soon, maybe this patch should
> be abandoned.
>
> At present, it is possible to say 'ghci -lpcre' or 'addDLL "lpcre"'. For
> these to work, you have to be able to call the system linker from ghci
> dynamically. (Therefore, I think it means replacing Linker.c with the
> native system linker.) Again, I'm all for this, but I don't know the
> difficulty involved.

See http://hackage.haskell.org/trac/ghc/ticket/3658

this in itself doesn't obsolete Linker.c, but it is a necessary first 
step, and more research needs to be done before we can decide whether 
obsoleting Linker.c is possible and practical.

Duncan is right to point out that linker script futzing in Linker.c 
won't be necessary if we make GHCi dynamically linked, and we certainly 
plan to do that in the 6.14 timeframe, so working on dynamically linking 
GHCi would be more useful in the long term.

Cheers,
	Simon