Ok, after changing this the linker error is gone. But now I get a compile error close to the place the linker error previously occurred: [28 of 79] Compiling Plugin.Activity ( Plugin/Activity.hs, dist/build/lambdabot/lambdabot-tmp/Plugin/Activity.o ) [...] Loading package IOSpec-0.2.5 ... linking ... done. Plugin/Activity.hs:18:10: Illegal instance declaration for `Module ActivityModule ActivityState' (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use -XFlexibleInstances if you want to disable this.) In the instance declaration for `Module ActivityModule ActivityState' cabal: Error: some packages failed to install: lambdabot-4.2.3.2 failed during the building phase. The exception was: ExitFailure 1 On 07/03/2012 09:47 PM, Brandon Allbery wrote:

On Tue, Jul 3, 2012 at 3:16 PM, Antoras mailto:mail@antoras.de> wrote:

Loading package readline-1.0.1.0 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib/libncurses.so (-lncursesw: cannot open shared object file: No such file or directory)

Your Linux distribution pulled a cute stunt that throws the dynamic loader (used for TH and ghci and a few other things) for a loop: libncurses.so, for backward compatibility purposes, is a GNU ld linker script which references libncursesw.so in a way the dynamic loader doesn't understand. You can work around this in one of two ways:

1. replace /usr/lib/libncurses.so with a symlink to /usr/lib/libncursesw.so; OR 2. edit /usr/lib/libncurses.so, which is a text file (linker script), to reference "/usr/lib/libncursesw.so" instead of "-lncursesw".

-- brandon s allbery allbery.b@gmail.com mailto:allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

Aha, I just found this which you may find helpful: https://github.com/DanBurton/lambdabot-remedies -Brent On Tue, Jul 03, 2012 at 08:51:33PM -0400, Brent Yorgey wrote:

This is what I mean by lambdabot being notoriously difficult to install. If you work through this one there will probably be another, and another... I did get it to compile once but it took quite a bit of effort.

You would probably be better off getting lambdabot's source from the darcs repository (http://code.haskell.org/lambdabot/) and trying to build that. Note that the last upload of the lambdabot package to Hackage was in January 2011 -- no one has a particular incentive to make sure the package stays up-to-date.

This particular error, I think, is caused by a change in the way GHC handles certain extensions. Apparently lambdabot has not been updated to match. You could fix it by editing Plugin/Activity.hs and adding

{-# LANGUAGE FlexibleInstances #-}

to the top.

-Brent

On Tue, Jul 03, 2012 at 11:23:58PM +0200, Antoras wrote:

...

Ok, after changing this the linker error is gone. But now I get a compile error close to the place the linker error previously occurred:

[28 of 79] Compiling Plugin.Activity ( Plugin/Activity.hs, dist/build/lambdabot/lambdabot-tmp/Plugin/Activity.o ) [...] Loading package IOSpec-0.2.5 ... linking ... done.

Plugin/Activity.hs:18:10: Illegal instance declaration for `Module ActivityModule ActivityState' (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use -XFlexibleInstances if you want to disable this.) In the instance declaration for `Module ActivityModule ActivityState' cabal: Error: some packages failed to install: lambdabot-4.2.3.2 failed during the building phase. The exception was: ExitFailure 1

On 07/03/2012 09:47 PM, Brandon Allbery wrote:

...

On Tue, Jul 3, 2012 at 3:16 PM, Antoras mailto:mail@antoras.de> wrote:

Loading package readline-1.0.1.0 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib/libncurses.so (-lncursesw: cannot open shared object file: No such file or directory)

Your Linux distribution pulled a cute stunt that throws the dynamic loader (used for TH and ghci and a few other things) for a loop: libncurses.so, for backward compatibility purposes, is a GNU ld linker script which references libncursesw.so in a way the dynamic loader doesn't understand. You can work around this in one of two ways:

1. replace /usr/lib/libncurses.so with a symlink to /usr/lib/libncursesw.so; OR 2. edit /usr/lib/libncurses.so, which is a text file (linker script), to reference "/usr/lib/libncursesw.so" instead of "-lncursesw".

-- brandon s allbery allbery.b@gmail.com mailto:allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

...

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners