On Mon, Jan 11, 2010 at 05:31:58AM +, Andrew Suffield wrote:
> On Mon, Jan 11, 2010 at 05:31:46AM +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.
> >
>
On Mon, Jan 11, 2010 at 05:31:46AM +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.
>
> If memory serves me right, you can register a COM DLL anywhere on the
> sys
On Sun, Jan 10, 2010 at 01:32:51PM +, Andrew Suffield wrote:
> On Sun, Jan 10, 2010 at 12:55:35PM +, Neil Mitchell wrote:
> > This isn't a patch that changes the default - I suspect Windows will
> > build static exes forever more. However, there are some circumstances
> > where you need Has
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 Sun Jan 10 19:00:01 GMT 2010.
**
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.
This does not appear to be an issue because the .so files are uniquely
na
On Sat, 2010-01-02 at 13:47 +, Simon Marlow wrote:
> We had a similar plan in the past, see e.g.
>
> http://www.haskell.org/pipermail/glasgow-haskell-users/2007-June/012740.html
>
> and for background:
>
> http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management
>
> However, Dun
On Sun, Jan 10, 2010 at 12:55:35PM +, Neil Mitchell wrote:
> This isn't a patch that changes the default - I suspect Windows will
> build static exes forever more. However, there are some circumstances
> where you need Haskell to build with DLL's (writing Haskell COM
> components for example),
Hi Andrew,
> It may be that the best way to do things on Windows (at least for now)
> is just to link Haskell code statically, and only use DLL support for
> FFI - ie, how things currently work.
This isn't a patch that changes the default - I suspect Windows will
build static exes forever more. H
On Sun, Jan 10, 2010 at 11:15:08PM +1100, Majestic Perch wrote:
> The problem we have is that when running the testsuite there are
> many directories containing many individual .hs files that need to
> be built and linked against the GHC libraries.. Adding a copy to
> each directory isn't really an
On Sun, Jan 10, 2010 at 05:24:17PM +1100, Ben Lippmeier wrote:
> I haven't pushed a patch to do this yet because the DLLs for the
> runtime and libraries currently require manual installation. After
> building GHC I've been doing a find . -name "*.dll" and copying
> all the results to c:\Windows
Build results:
x86-64 Linux head: fail (exception darcs)
x86 Windows head:pass
x86 Windows head fast: pass lost lost pass
x86-64 Linux head unreg: fail (exception darcs)
Old unexpected test passes:
2410 2 x86-64 Linux head
TH_spliceE5_prof 2 x86-64 Linux head
Build results:
x86 Windows stable: pass lost
x86 Windows stable fast: pass lost lost pass
x86-64 Linux stable: fail (exception darcs)
Old unexpected test passes:
2410 2 x86 Windows stable
TH_spliceE5_prof 2 x86 Windows stable
newtype 2 x86 Windows stable
12 matches
Mail list logo
