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
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
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
> s
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
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
Windows DLLs should be working now. To turn on the "dyn" way add the
string "i386-unknown-mingw32" to PlatformSupportsSharedLibs in mk/config.mk
I haven't pushed a patch to do this yet because the DLLs for the runtime
and libraries currently require manual install
11 matches
Mail list logo
