Re: Problem linking on Win32

On 10/9/06, Jason Dagit wrote:

On 10/9/06, Lemmih wrote:

...

On 10/9/06, Jason Dagit wrote:

...

Hello,

I have a program and I'd like to permanently change the default RTS options. According to the GHC manual I can do that by linking with a snippet of C code: http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html

Look at section 4.14.5 at the bottom of the page.

I can't seem to get cabal to link my program together so that my custom rts options take affect. To help demonstrate I've created a minimal test case:

------------- oom.cabal ------------------- name: OutOfMemory version: 0.1 cabal-version: -any license: AllRightsReserved license-file: "" build-depends: base -any c-sources: rtsoptions.c exposed-modules: Main

Executable: oom Main-is: Main.hs ------------- end oom.cabal -----------

--------------- Main.hs --------------------- module Main where

main :: IO () main = print $ foldl (+) 0 [1..100000000] --------------- End Main.hs --------------

/* rtsoptions.c */ char *ghc_rts_opts = "-M1024M -K256M"; /* end rtsoptions.c */

Also using the standard Setup.lhs: #! /usr/bin/runghc

\begin{code} import Distribution.Simple main = defaultMain \end{code}

When build and run this I get: C:\projects\tmp>runghc Setup.lhs build Preprocessing library OutOfMemory-0.1... Preprocessing executables for OutOfMemory-0.1... Building OutOfMemory-0.1... [1 of 1] Compiling Main ( Main.hs, dist\build\oom\oom-tmp/Main.o ) Linking dist\build\oom\oom.exe ...

C:\projects\tmp>dist\build\oom\oom.exe Heap exhausted; Current maximum heap size is 268435456 bytes (256 Mb); use `+RTS -M<size>' to increase it.

On the other hand, if I build rtsoptions.c manually and add it to the ghc-options line in the .cabal file it does build and run until in needs more than 976Mb (showing that the default RTS options are indeed different).

Add the C source to the executable instead of the library. In other words, move the 'c-sources' under 'main-is'.

Ah yes. I feel silly now to have been stumped on this so long. As soon as you say it, it makes instant sense since Cabal conceptually keeps the library stanza separate from executable stanzas.

Perhaps it would help if cabal throw a warning when the first stanza is not separate from the 'meta data' by a blank line. So that the library stanza is always standing by itself too. Just a thought.

Hmm...Actually, just looking at my real program and not the 'minimal' example above my cabal file looks like this and was (mostly) autogenerated by visual haskell: name: Analyzer version: 0.1 cabal-version: -any license: AllRightsReserved license-file: "" copyright: maintainer: build-depends: HaXml ==1.13, QuickCheck ==1.0, base -any, haskell-src ==1.0, haskell98 ==1.0, mtl ==1.0, parsec ==2.0, template-haskell ==1.0, wx ==0.9.4, wxcore ==0.9.4 stability: homepage: package-url: synopsis: description: category: author: tested-with: data-files: extra-source-files: extra-tmp-files: exposed-modules: Excel.Formula, Excel.Layout, Excel.SpreadSheetML, Excel.SpreadSheetUtil, Parser.Common, Parser.NodeEval, Report.Logic.Common, Report.Logic.Delay, Report.Logic.NodeEval, Report.Logic.TravelTime, Report.Template.Common, Report.Template.Delay, Report.Template.NodeEval, Report.Template.TravelTime, Main, Report, Tests, Utility buildable: True cc-options: ld-options: frameworks: c-sources: src/DllMain.c src/rtsoptions.c extensions: CPP extra-libraries: extra-lib-dirs: includes: install-includes: include-dirs: hs-source-dirs: src other-modules: ghc-prof-options: -prof -auto-all -caf-all ghc-options: -fglasgow-exts -Wall -Werror -O2 -funbox-strict-fields -static -optl-mwindows src/rtsoptions.o --ghc-options: -fglasgow-exts -Wall -Werror -O2 -funbox-strict-fields -static src/rtsoptions.o hugs-options: nhc-options: jhc-options: Here you see that I don't have a separate executable stanza, cabal does build me an executable. Where would I put rtsoptions.c in this cabal file to get it to link in properly? Thanks, Jason