Re: Bug#294481: ghci -lpthread fails
On Wed, Feb 09, 2005 at 11:13:36PM +0100, Juliusz Chroboczek wrote:
Package: ghc6 Version: 6.2.2-2
/usr/lib/libpthread.so (comes from libc6-dev 2.3.2.ds1-20) is a GNU linker script, not a shared object. This breaks ghci.
Known problem: http://www.haskell.org/pipermail/glasgow-haskell-users/2004-May/006671.html What is your particular problem? CCing glasgow-haskell-users@haskell.org as someone there may have an answer, or be interested to know the problem exists if not. Thanks Ian
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. Thanks Ian
On Thu, 2005-02-10 at 16:58 +0000, Ian Lynagh wrote:
On Wed, Feb 09, 2005 at 11:13:36PM +0100, Juliusz Chroboczek wrote:
Package: ghc6 Version: 6.2.2-2
/usr/lib/libpthread.so (comes from libc6-dev 2.3.2.ds1-20) is a GNU linker script, not a shared object. This breaks ghci.
Known problem:
http://www.haskell.org/pipermail/glasgow-haskell-users/2004-May/006671.html
What is your particular problem?
CCing glasgow-haskell-users@haskell.org as someone there may have an answer, or be interested to know the problem exists if not.
There are two workarounds that I know of: * simply omit -lpthread. This often works since pthread is a dependency of other libs so it will just work automatically. * use -pthread instead of -lpthread. This is valid option to gcc and tells it to link in the pthreads library. However ghci does not recognise the option so ghci will not load pthread itself (but hopefully it will be pulled in as a dependency by the dynamic linker) but when doing ordinary linking with ghc the program will be linked to the pthreads shared library. The -pthread option has to go in "extra_ld_opts" in the package file. You cannot just stick -lpthread in the extra_ld_opts since ghci will notice any options which look like -l* and load the libs anyway. Duncan
participants (3)
-
Duncan Coutts -
Ian Lynagh -
Juliusz Chroboczek