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 [email protected]
* 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
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
