Re: rpath for shared libraries

On Tue, Jan 12, 2010 at 12:16:31AM +, Duncan Coutts wrote: > On Mon, 2010-01-11 at 20:19 +, Andrew Suffield wrote: > > > To reiterate, this is the exemplar use case for relocatable objects: > > > > Install ghc and some libraries to /usr/local/ > > Build some applications with ghc and inst

[nightly] 11-Jan-2010 build of HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com)

Build description = HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com) Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx Nightly build started on cam-04-unx at Mon Jan 11 19:00:02 GMT 2010. **

Re: Windows DLLs should be working.

Duncan Coutts wrote: On Sun, 2010-01-10 at 17:24 +1100, Ben Lippmeier wrote: Windows DLLs should be working now. Huzza. Great work Ben. So what was the solution in the end to the problem of the cross-module inlining and making intra vs inter DLL-calls? The solution was to refacto

Re: rpath for shared libraries

On Mon, 2010-01-11 at 20:19 +, Andrew Suffield wrote: > To reiterate, this is the exemplar use case for relocatable objects: > > Install ghc and some libraries to /usr/local/ > Build some applications with ghc and install them into /home/asuffield/bin/ > mv /usr/local/lib/*ghc* /srv/nfs-app-s

Re: rpath for shared libraries

On Mon, Jan 11, 2010 at 04:32:02PM +, Duncan Coutts wrote: > There are advantages to not doing so. In particular multiple instances > of the same version of a package, or multiple instances of the same ghc > version can co-exist happily if they're isolated. Why is this useful? I can't imagine

Re: rpath for shared libraries

On Sun, 2010-01-10 at 21:22 +, Andrew Suffield wrote: > On Sun, Jan 10, 2010 at 07:11:43PM +, Duncan Coutts wrote: > > Right. I think it's much more sensible to use isolated locations for > > installed library files. It makes it much easier to have multiple > > instances of things. > > Thi

Re: Windows DLLs should be working.

On Mon, 2010-01-11 at 05:31 +0100, Lars Viklund wrote: > > If you want to get this working with COM, then building an assembly > > out of the DLLs is probably mandatory. So that's looking like the way > > to go. Yes, we'll want to be able to make and use assemblies. Not just for COM, it's the gen

Re: Windows DLLs should be working.

On Sun, 2010-01-10 at 17:24 +1100, Ben Lippmeier wrote: > Windows DLLs should be working now. Huzza. Great work Ben. So what was the solution in the end to the problem of the cross-module inlining and making intra vs inter DLL-calls? > To turn on the "dyn" way add the > string "i386-unknown-min

Re: DPH libs are re-haddocked every time

On Thu, 2010-01-07 at 14:29 +, Simon Marlow wrote: > > I don't think haddock should be doing any pre-processing, but certainly > > we should not be telling it to generate the same .o files as we do for > > the main build. > > > > So if we changed the way Cabal invokes haddock to point it to a

patch applied (/haskell/ghc): Update the emacs mode link

Mon Jan 11 05:25:32 EST 2010 Ian Lynagh * Update the emacs mode link M ./ghc-std.html -2 +2 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (/haskell/ghc): Fix link to the GHC trac

Mon Jan 11 05:24:24 EST 2010 Ian Lynagh * Fix link to the GHC trac M ./ghc-std.html -1 +1 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

Daily report for stable

Build results: sparky stable: fail (failed compile) x86 Windows stable fast: pass Old unexpected test passes: 2410 2 x86 Windows stable TH_spliceE5_prof 2 x86 Windows stable newtype 2 x86 Windows stable prof001 2 x86 Windows stable prof

Daily report for head

Build results: x86 Windows head fast: pass Old unexpected test passes: 2410 2 x86-64 Linux head TH_spliceE5_prof 2 x86-64 Linux head length0011 tnaur x86 OS X head newtype 2 x86-64 Linux head prof001 2 x86-64 Linux head prof002