Hello glasgow-haskell-users, when GHC builds executable, it adds debug info by default. since this info is useless for Haskell and since it significantly increases executable size, will it be better to delete it by default by passing -optl-s option to the linker? another question: by adding " -optl-Xlinker -optl--large-address-aware" to cmdline we will allow mingw32-compiled programs to use up to 4gb of memory (instead of 2gb with current settings). now i have 4gb of memory+vista64 so can test this setting if required -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
bulat.ziganshin:
Hello glasgow-haskell-users,
when GHC builds executable, it adds debug info by default. since this info is useless for Haskell and since it significantly increases executable size, will it be better to delete it by default by passing -optl-s option to the linker?
another question: by adding " -optl-Xlinker -optl--large-address-aware" to cmdline we will allow mingw32-compiled programs to use up to 4gb of memory (instead of 2gb with current settings). now i have 4gb of memory+vista64 so can test this setting if required
You can also achieve this by making sure your deployed programs build with Cabal, http://www.haskell.org/pipermail/cabal-devel/2008-March/002427.html No need to hack GHC's view of the linker.
Hello Don, Friday, September 12, 2008, 12:54:22 PM, you wrote:
You can also achieve this by making sure your deployed programs build with Cabal,
*my* programs are built using these opts, how about other haskellers? it comes to surprise that executables contains lot of useless data. second problem is probably rather specific, though -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Fri, 2008-09-12 at 13:06 +0400, Bulat Ziganshin wrote:
Hello Don,
Friday, September 12, 2008, 12:54:22 PM, you wrote:
You can also achieve this by making sure your deployed programs build with Cabal,
*my* programs are built using these opts, how about other haskellers?
Cabal automatically strips executables on installation and has the option --disable-executable-stripping to disable that. So packages authors do not have to do anything, indeed they should not try to add any flags to force stripping as that would prevent --disable-executable-stripping from working. Hackage checks for this. Duncan
Hello Don, Friday, September 12, 2008, 12:54:22 PM, you wrote:
when GHC builds executable, it adds debug info by default. since this You can also achieve this by making sure your deployed programs build with Cabal, http://www.haskell.org/pipermail/cabal-devel/2008-March/002427.html No need to hack GHC's view of the linker.
btw, it seems like hack in 3rd party tool to fix weird default ghc behavior -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Don,
Friday, September 12, 2008, 12:54:22 PM, you wrote:
when GHC builds executable, it adds debug info by default. since this You can also achieve this by making sure your deployed programs build with Cabal, http://www.haskell.org/pipermail/cabal-devel/2008-March/002427.html No need to hack GHC's view of the linker.
btw, it seems like hack in 3rd party tool to fix weird default ghc behavior
It might be weird, but it's traditional. Also the symbol information is sometimes useful: for example on Linux Valgrind understands it and can tell you which function has memory errors, or give you a profile (perhaps only useful for people working on the RTS like me). I don't feel that strongly about it though. Cheers, Simon
On Thu, 2008-09-18 at 13:54 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello Don,
Friday, September 12, 2008, 12:54:22 PM, you wrote:
when GHC builds executable, it adds debug info by default. since this You can also achieve this by making sure your deployed programs build with Cabal, http://www.haskell.org/pipermail/cabal-devel/2008-March/002427.html No need to hack GHC's view of the linker.
btw, it seems like hack in 3rd party tool to fix weird default ghc behavior
It might be weird, but it's traditional. Also the symbol information is sometimes useful: for example on Linux Valgrind understands it and can tell you which function has memory errors, or give you a profile (perhaps only useful for people working on the RTS like me).
And some distros have a policy of managing striping themselves (and making it a user preference and allowing either stripping, no stripping or putting debug info in separate files on another part of the file system). Yes it's true that that debug info is not usually useful for Haskell progs like it is for C ones but just doing the same thing as other packages makes life easier for those distros. So the ability to turn it on/off easily when building is reasonably important and that's exactly the situation we have now with Cabal packages. So I think it's fine to leave the stripping feature there rather than pushing it lower into ghc (as we'd still need to be able to turn it on/off). Basically the status-quo is fine, imho. Duncan
participants (4)
-
Bulat Ziganshin -
Don Stewart -
Duncan Coutts -
Simon Marlow