On Fri, Jan 29, 2010 at 09:30:38AM +, Simon Marlow wrote:
> The openTempFile001 failure is probably harmless, it just indicates
> that we tried to write a character that isn't known in your current
> locale (maybe you can set your locale to a Unicode one, I can't
> remember how to do that on Wi
On Tue, Jan 12, 2010 at 08:22:48AM +, Duncan Coutts wrote:
> man ld.so says:
>
> The shared libraries needed by the program are searched for in the
> following order:
>
> * (ELF only) Using the directories specified in the DT_RPATH
> dynamic section attribute of the binary if
On Tue, Jan 12, 2010 at 12:16:31AM +, Duncan Coutts wrote:
> On Mon, 2010-01-11 at 20:19 +0000, Andrew Suffield wrote:
>
> > To reiterate, this is the exemplar use case for relocatable objects:
> >
> > Install ghc and some libraries to /usr/local/
> > Build
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
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 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 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),
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
> In short, a `foreign export` is not a type signature at all. It's a
> ''use'' of `foo`.
Yes, but the diagnostic doesn't point you to the right location. After
sleeping on it, this is an instance of a more general issue with type
checking errors: they're following the model of an explicitly ty
On Tue, Jan 05, 2010 at 09:54:41AM +, Simon Marlow wrote:
> I've also seen failures that look suspiciously like attempts to run
> more than one ghc-pkg at the same time, which as far as I know the
> build system is not supposed to do.
It's difficult to get make to understand this sort of thing
On Fri, Jan 01, 2010 at 01:38:58AM +0100, Lars Viklund wrote:
> On Wed, Dec 30, 2009 at 06:29:23PM +0000, Andrew Suffield wrote:
> > I've been thinking about this. The only reason why rpath is needed is
> > because the .so files are being stuck in lib/ghc-$version/ instead o
On Thu, Dec 31, 2009 at 02:34:33PM +, Ian Lynagh wrote:
> * Why does HSdph-prim-par-0.4.0-ghc6.13.20091222 have filename
> libHSdph-prim-seq-0.4.0-ghc6.13.20091222.so
> (note par vs seq)
Probably because -par-*.so is linked against -seq-*.so; the error
message is from dlopen(), which
On Wed, Dec 30, 2009 at 02:20:41PM +, Duncan Coutts wrote:
> On Wed, 2009-12-30 at 12:09 +0100, Maxime Henrion wrote:
>
> > - Is there a plan to deal with the ldconfig cache on UNIX systems? As
> > things are now, I had to manually add all the package directories
> > under /usr/local/lib/ghc-6
On Wed, Dec 30, 2009 at 12:09:08PM +0100, Maxime Henrion wrote:
> - Is there a plan to deal with the ldconfig cache on UNIX systems? As
> things are now, I had to manually add all the package directories
> under /usr/local/lib/ghc-6.12.1/ to be able to run the generated
> executable. I guess Cabal
15 matches
Mail list logo
