On Fri, 2005-12-09 at 15:04 +0100, Sven Panne wrote: > Am Mittwoch, 7. Dezember 2005 12:21 schrieb Duncan Coutts: > > On Fri, 2005-12-02 at 11:06 +0000, Simon Marlow wrote: > > > On 30 November 2005 12:29, Duncan Coutts wrote: > > > > Attached is a simple code change to allow packages to specify a > > > > different list of "extra libraries" to link with when using the ghci > > > > and dlopen/LoadLibrary compared to when using the native system > > > > linker. > > > > > > Yes to the idea in principle; please go ahead and complete the patch. > > > > Ok, attached is the full patch. It has to be in two parts since the > > darcs repos for ghc and the libraries are separate. > > > > I've briefly tested the change. I built Gtk2Hs with ghc-6.5 with the > > patch. I modified (and registered) the gtk.package.conf file so that it > > specified: > > > > extra-libraries: "gtk-x11-2.0", [...snip...], "pthread" > > extra-ghci-libraries: "gtk-x11-2.0", [...snip...] > > [...] > > Hmmm, I haven't followed the thread too closely, but aren't we just hacking > around the real cause here? Wouldn't it be better to teach GHCi's linker > about the ld scripts, at least in a very basic form? My concern is that the > proposed hack puts additional burden onto the autoconf magic of package > developers and makes doing "the right thing" portably quite tricky, I > guess...
The other magic you'd have to teach GHCi's linker about is the case where the libfoo.a tells the runtime loader to use not "foo.so" but something slightly different like "foo-v1.so". This is the problem we have with Gtk+ on Win32. The "libgtk-win32-2.0.a" file instructs the windows runtime loader to use "libgtk-win32-2.0-0.dll". Obviously that works fine when ghc uses the system linker. However it fails when GHCi uses it's own linker. Another way of solving this would be if the GHC packages loaded by GHCi were native system dynamic libraries. Then the ordinary system linker would be used to create them and they would be linked against the right runtime .so/.dll files. That would also deal with the case of GNU ld scripts. However until we get packages as native dynamic libs we could still do with a solution. I appreciate that it is not an ideal solution. I do not expect it to be used very widely or for very long (basically until we get native dynamic libs). If we leave it as it is developers still have to do autoconf magic to do the workarounds. They've got to strip out libraries that are gnu ld scripts and just pray that some other lib implicitly depends upon the one they removed from the libs list. And sometime it's impossible to workaround (as in the case of Gtk2Hs on Win32). Duncan _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
