I think that butterfly effect piece pretty much exactly described my problems with trying to install yesod and warp. Installing one would uninstall the other. On Thu, Mar 24, 2011 at 12:56 PM, Thomas Hartman < thomashartman1@googlemail.com> wrote:

I'm not sure but my guess is these problems are caused by underlying problem in cabal. See

http://cdsmith.wordpress.com/2011/01/21/a-recap-about-cabal-and-haskell-libr... http://cdsmith.wordpress.com/2011/01/17/the-butterfly-effect-in-cabal/

...

Thanks. So what exactly is the real issue? Is something requiring multiple versions of Network as indicated above, or is it a more 'permanent'

On Thu, Mar 24, 2011 at 9:50 AM, Rick Richardson wrote: problem?

...

On Thu, Mar 24, 2011 at 2:54 AM, Michael Snoyman wrote:

...

What Blake suggests in the right solution, except for two points (which are beyond his control):

* It's a bit unfair to make users remember to install yesod with -fproduction. * wai-handler-devel does not handle Hamlet dependency tracking. That means that if you use Blake's suggestion and then modify your Hamlet templates, your code will not be reloaded.

So I've released new versions of wai-handler-devel (0.2.1) and yesod (0.7.2). There's no such thing as the -fproduction flag to yesod: it will never build against wai-handler-devel. When you call the develServer function, it will simply print out a message apologizing that it cannot fulfill your request, and will tell you to install wai-handler-devel >= 0.2.1 and run a command such as:

wai-handler-devel 3000 Controller withTest --yesod

Notice that extra --yesod at the end? That's the new feature in 0.2.1. I moved the Hamlet dependency checking code from yesod to wai-handler-devel. So now, if you run your application this way, Hamlet changes will automatically result in a reload of your code.

I tried to set up the develServer function to automatically run wai-handler-server, but it resulted in the same error messages from GHC. Oh well. I image in future versions of the scaffolding tool, the devel-server.hs function will do all this for you automatically.

Please let me know if this new approach causes any issues.

Michael

On Thu, Mar 24, 2011 at 1:00 AM, Blake Rain

wrote:

...

...

...

I too had a the same problem with duplicate symbols from libHSghc, and it seems to be a problem with yesod's dynamic server (or perhaps with Hint).

My solution was first to remove the dependency on wai-handler-devel in the yesod package by using the 'production' flag, like so:

$ cabal install yesod -fproduction

For running a dynamic server, the wai-handler-devel package installs an executable called wai-handler-devel. You can use this rather than the "runhaskell devel-server.hs" by providing the port, module and function from your "devel-server.hs" file as arguments:

$ wai-handler-devel 3000 MySiteModule withMySite

The dynamic recompilation of wai-handler-devel is very useful, and I hope this helps.

On Wed, 2011-03-23 at 14:22 -0400, Rick Richardson wrote:

...

I removed all but network-2.2.1.0 and rebuilt everything, still no luck. But I'm sure you have set me on the right track, I will experiment with other permutations.

Thanks.

On Wed, Mar 23, 2011 at 1:27 PM, Anton Cheshkov

...

...

...

wrote: Hi Rick! I got the the same error day ago on my server. Probably it happens because you have two network packages in you system.

Try to compile all your packages only on network-2.2.1.10, and delete package network-2.3

Hope it helps you

2011/3/23 Rick Richardson

I just installed the generic 7.0.2 binary on Ubuntu on both 32 bit and 64 bit machines. Then I rm'd .ghc and .cabal then fetched the current haskell platform. Built and installed.

After cabal installing all of the dependencies cabal said were required for yesod, I run yesod.. the script creates the project.

When executing runhaskell devel-server.hs I get this message

GHCi runtime linker: fatal error: I found a duplicate definition for symbol ghczm7zi0zi2_AsmCodeGen_zdfMonadCmmOptM2_closure whilst processing object file

/usr/local/lib/ghc-7.0.2/ghc-7.0.2/libHSghc-7.0.2.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry.

it's the same on both 32 and 64 bit.

Any ideas? I am going to try to build 7.0.2 from source to see if that fixes it.

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

-- Best regards, Cheshkov Anton Phone: +7 909 005 18 82 Skype: cheshkov_anton

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel