Bug#294481: ghci -lpthread fails

Simon Marlow simonmar at microsoft.com
Fri Feb 11 06:27:21 EST 2005

On 10 February 2005 23:35, Ian Lynagh wrote:

> On Thu, Feb 10, 2005 at 07:00:47PM +0100, Juliusz Chroboczek wrote:
>> Hi Ian,
>>> What is your particular problem?
>> Running Darcs under ghci.
> This seems to work for me (at least in as much as ghci loads and
>     FastPackedString.lengthPS (FastPackedString.packString "Foo")
> says 3):
> rm -rf .libs
> rm *ghcidarcsfoo*
> touch ghcidarcsfoo.c
> libtool --mode=compile gcc -g -O -c ghcidarcsfoo.c
> libtool --mode=link gcc -g -O -o libghcidarcsfoo.la ghcidarcsfoo.lo
> -lpthread -rpath /usr/lib 
> libtool --mode=install cp libghcidarcsfoo.la `pwd`/libghcidarcsfoo.la
> libtool --finish /usr/lib
> ghci -cpp -package unix -package parsec -O -funbox-strict-fields
> -Werror -package util -I. -DHAVE_CURSES -optl-lcurses -optl-lz
> -L`pwd` -optl-lghcidarcsfoo darcs.lhs compat.o fpstring.o
> zlib_helper.o c_context.o   
> Is there a problem with this? Could something along these lines be
> done 
> when -lfoo (as opposed to -optl-lfoo, which for consistency should
> probably be left alone) is given on the ghci command-line?
> I'm no library expert, so there may be a cleaner/simpler/more portable
> equivalent to the above.

I'm not that familiar with libtool, but I guess what  you're doing here
is creating a dummy shared library which is linked against -lpthread,
and linking that into GHCi?

I don't see any reason why we couldn't automate the process, except that
getting all the fiddly details right would probably be a nightmare.  And
would you require libtool to be installed?  What about other platforms -
Mac OS X?


More information about the Glasgow-haskell-users mailing list