May 2005 - Glasgow-haskell-users

RE: ghc-6.4 fPIC compilation problem on amd64
by ariep＠xs4all.nl 13 May '05

13 May '05

> That's a new one on me. Does your 6.2.2 build otherwise work, i.e. can > you build & run programs with it? ghc won't even compile a 'main = putStrLn "hello world"' program: | # ghc --make Main.hs | Chasing modules from: Main.hs | Compiling Main ( Main.hs, Main.o ) | Linking ... | /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: Main.o: relocation R_X86_64_32 against `__stginit_Main_' can not be used when making a shared object; recompile with -fPIC | Main.o: could not read symbols: Bad value | collect2: ld returned 1 exit status :( Greetings, Arie

1 0

Fwd: Re[2]: Unicode source files
by Bulat Ziganshin 13 May '05

13 May '05

Sorry, Simon, are you received this message? This is a forwarded message From: Bulat Ziganshin <bulatz(a)HotPOP.com> To: "Simon Marlow" <simonmar(a)microsoft.com> Date: Thursday, May 05, 2005, 10:13:37 PM Subject: Unicode source files ===8<==============Original message text=============== Hello Simon, Thursday, May 05, 2005, 1:56:12 PM, you wrote: >> it is true what to support unicode source files only StringBuffer >> implementation must be changed? SM> It depends whether you want to support several different encodings, or SM> just UTF-8. If we only want to support UTF-8, then we can keep the SM> StringBuffer in UTF-8 and also FastStrings. (or you could re-encode the SM> other encodings into UTF-8). srcParseErr contains call to "stepOnBy (-len)", and doing this will be hard with UTF-8. although we can save pointer(s) to positions of previous chars or even just reparse from scratch entire buffer - printing source errors is not so frequent task. of course, it will be great to just save this position for us :) making FastString UTF-8-enabled would be great. it needs changes in lengthFS, indexFS and may be cmpFS (can the UTF-8 chars be compared with just memcmp?). also i don't know about hPutFS. win32 console works in either oem or ansi 8-bit encoding SM> The question is what Alex should see for a unicode character: Alex SM> currently assumes that characters are in the range 0-255 (you need a SM> fixed range in order to generate the lexer tables). One possibility is SM> to map all Unicode upper-case characters to a single character code for SM> Alex, and similarly for the other classes of character. i don't know anything about Alex intrinsics, and can only say that any solution is better to do INSIDE Alex, so other programs using it will also get Unicode support ... if this problem is just about changing charType in Ctype.lhs - we can use some sort of hack. for example, use current scheme until there is some char greater than (chr 255). in this moment we create array for classification of chars 256-65535. all chars greater than (chr 65535) is better to recognize with calls to appropriate functions, i think btw, Ruby supports writing numbers in form 1_200_000. how about adding this feature to GHC? ;) Lexer.x: @decimal = $digit [$digit \_]* @octal = [$octit \_]+ @hexadecimal = [$hexit \_]+ StringBuffer.lhs: parseInteger :: StringBuffer -> Int -> Integer -> (Char->Int) -> Integer parseInteger buf len radix to_int = go 0 0 where go i x | i == len = x | otherwise = case (lookAhead buf i) of '_' -> go (i+1) x c -> go (i+1) (x * radix + toInteger (to_int c)) -- Best regards, Bulat mailto:bulatz@HotPOP.com ===8<===========End of original message text=========== -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

Why would my bugreports not have been responded to?
by Samuel Bronson 12 May '05

12 May '05

I sent a couple of bug reports to the glasgow-haskell-bugs list, and I'm wondering why nobody seems to have responded yet. Should I have used the sourceforge bug tracker? Are they maybe just hard? Am I just being unreasonably impatient? -- Thanks, Sam

1 0

[ ghc-Feature Requests-1084122 ] RPM doesn't support --prefix
by SourceForge.net 11 May '05

11 May '05

Feature Requests item #1084122, was opened at 2004-12-13 10:54 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: John Skaller (skaller) Assigned to: Nobody/Anonymous (nobody) Summary: RPM doesn't support --prefix Initial Comment: After installing ghc for linux using rpm with --prefix=/usr/local, the ghc scriipt incorrectly thinks the libraries etc are in /usr: #!/bin/sh GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2"; TOPDIROPT="-B/usr/lib/ghc-6.2.2"; # Mini-driver for GHC exec $GHCBIN $TOPDIROPT ${1+"$@"} After editing, at least the compiler actually starts up :) ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-12 11:08 Message: Logged In: YES user_id=139853 This is now fixed in Fedora Haskell as of ghc-6.4-7. I will send in a spec file patch "as soon as the dust settles". Feel free to assign this to me. :) ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 08:57 Message: Logged In: YES user_id=139853 Not really sure what the right solution is - one hack that comes to mind is adding a %post install script in the spec file that would replace the default prefix with the specified one. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-04-12 22:06 Message: Logged In: NO Still a problem with 6.2.4 - Additionally, you now need to edit the package.conf file. Karl M. Syring syring(a)email.com ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2004-12-14 01:26 Message: Logged In: YES user_id=48280 Re-opened. Any RPM gurus out there who could knock this one on the head? Note it's not just the ghc script, there's a couple of other scripts that need munging (ghci, ghc-pkg, hsc2hs maybe). ---------------------------------------------------------------------- Comment By: John Skaller (skaller) Date: 2004-12-13 23:54 Message: Logged In: YES user_id=5394 I can see it isn't supported :) However after the change to those two lines, the compiler works, links libraries, and the resultant binary executes correctly (as far as I can tell never having written any Haskell before .. :) So why not support it? I had no choice .. my root partition, containing /usr is 97% full.. :) ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2004-12-13 21:54 Message: Logged In: YES user_id=48280 You're trying to install the binary RPM using a different prefix? That's not supported, I'm afraid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_…

1 0

Fedora Haskell ghc-6.4 package is now relocatable
by Jens Petersen 11 May '05

11 May '05

An updated ghc packages for Fedora Core are now available from Fedora Haskell: <http://haskell.org/fedora/>. The ghc-doc subpackage now include all the docs - not just those of the libraries. The package is now relocatable, since this has been requested by a number of people. For x86-64 users there are also a few backported fixes. Enjoy, Jens ----------------------------------------------------------------------------- * Wed May 11 2005 Jens Petersen <petersen(a)haskell.org> - 6.4-7 - make package relocatable (ghc#1084122) - add post install scripts to massage prefix in driver scripts appropriately * Fri May 6 2005 Jens Petersen <petersen(a)haskell.org> - 6.4-6 - add ghc-6.4-dsforeign-x86_64-1097471.patch and ghc-6.4-rts-adjustor-x86_64-1097471.patch from trunk to improve ffi on x86_64 (Simon Marlow, ghc#1097471) - use XMLDocWays instead of SGMLDocWays to build documentation fully * Mon May 2 2005 Jens Petersen <petersen(a)haskell.org> - 6.4-5 - add rts-GCCompact.h-x86_64.patch to fix GC issue on x86_64 (Simon Marlow) * Thu Mar 17 2005 Jens Petersen <petersen(a)haskell.org> - 6.4-4 - add ghc-6.4-powerpc.patch (Ryan Lortie) - disable building interpreter rather than install and delete on x86_64

1 0

RE: ghc-6.4 fPIC compilation problem on amd64
by Simon Marlow 11 May '05

11 May '05

On 10 May 2005 16:29, ariep(a)xs4all.nl wrote: > When trying to compile ghc-6.4 from source on my amd64 using a 6.2.2 > binary (obtained via gentoo portage), I get the following error > message: > > ##### > make all > [...] > /usr/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall > -fno-warn-name-shadowing > -fno-warn-unused-matches -i../../lib/compat -Rghc-timing > -L../../lib/compat -lghccompat Main.o Version.o > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/b in/ld: > Main.o: relocation R_X86_64_32 against `__stginit_Main_' can not be > used when making a shared object; recompile with -fPIC > Main.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > <<ghc: 6713240 bytes, 3 GCs, 68040/68040 avg/max bytes residency (1 > samples), 6M in use, 0.00 INIT (0.00 elapsed), 0.03 MUT (0.03 > elapsed), > 0.00 GC (0.02 elapsed) :ghc>> > make[4]: *** [ghc-pkg.bin] Error 1 > ##### That's a new one on me. Does your 6.2.2 build otherwise work, i.e. can you build & run programs with it? > I added -fPIC to CFLAGS, LDFLAGS and the ghc options (the latter by > './configure --with-ghc="/usr/bin/ghc -fPIC"'), without effect: ghc > does not know an -fPIC, the other two attempts gave the same error > message as above. GHC doesn't support -fPIC on amd64 right now. Maybe it will in the future. Cheers, Simon

1 0

ghc-6.4 fPIC compilation problem on amd64
by ariep＠xs4all.nl 10 May '05

10 May '05

Hi, When trying to compile ghc-6.4 from source on my amd64 using a 6.2.2 binary (obtained via gentoo portage), I get the following error message: ##### make all [...] /usr/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall -fno-warn-name-shadowing -fno-warn-unused-matches -i../../lib/compat -Rghc-timing -L../../lib/compat -lghccompat Main.o Version.o /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: Main.o: relocation R_X86_64_32 against `__stginit_Main_' can not be used when making a shared object; recompile with -fPIC Main.o: could not read symbols: Bad value collect2: ld returned 1 exit status <<ghc: 6713240 bytes, 3 GCs, 68040/68040 avg/max bytes residency (1 samples), 6M in use, 0.00 INIT (0.00 elapsed), 0.03 MUT (0.03 elapsed), 0.00 GC (0.02 elapsed) :ghc>> make[4]: *** [ghc-pkg.bin] Error 1 ##### I added -fPIC to CFLAGS, LDFLAGS and the ghc options (the latter by './configure --with-ghc="/usr/bin/ghc -fPIC"'), without effect: ghc does not know an -fPIC, the other two attempts gave the same error message as above. What am I doing wrong? Thank you for your time, Arie Peterson

1 0

RE: Porting the GHC to GNU/Hurd
by Simon Marlow 10 May '05

10 May '05

On 09 May 2005 17:56, Thomas Schwinge wrote: >>>> On 10 April 2005 14:20, I wrote: >>>>> Is someone aware of any efforts to port the GHC to GNU/Hurd? >>>>> If not, I'd like to give that a try. > > I succeeded. :-) Thanks! I've committed all your patches, and merged them onto the 6.4 branch. Cheers, Simon

1 0

RE: GHC as library
by Simon Marlow 10 May '05

10 May '05

On 10 May 2005 03:42, Robert Dockins wrote: > I seem to recall some time ago the Simons asked on one of these lists > about uses people might have for GHC-as-library. It sounded really > neat to me, and I just kind of wonder if there is any motion on that > front. > > I'm thinking about hacking up a system to extract proof obligations > into Coq (http://coq.inria.fr/) from Haskell, and being able to get > my hands on various things would be really nice (like being able to > get at the AST after typechecking, but before conversion to core). The CVS HEAD contains our current work on GHC as a library. The interface is already useful, we're using it in the Visual Studio extension, and we've restructured GHC itself to put our existing front ends on top of this interface. Take a look in ghc/compiler/main/GHC.hs. Cheers, Simon

1 0

Bootstrapping using a C compiler (was: RE: Can't compile GHC)
by Simon Marlow 10 May '05

10 May '05

Thanks for all the comments in this thread. I'm going to describe some of the technical issues with making a GHC distribution that you can bootstrap on any platform from a single set of sources below. But first, let me explain our thinking on why we don't consider this a priority: we aim to provide working binary distributions for 99.9% of the potential users of GHC. Once you have a working binary of GHC, building GHC again should be easy (if you run into problems, it's a *high* priority from our point of view to fix it). For the other 0.1%, we provide detailed instructions for porting GHC to your platform. It works, but it's a tricky process. Once you have *one* working GHC, you can build future versions probably for at least 4 years (we pull the ladder up after ourselves to avoid #ifdef-hell in the compiler). It may be that we don't have that 99.9% figure for 6.4, but when you consider versions back to 5.02 (the oldest version we can build 6.4 with, I believe), it's probably true. If your platform has a binary distribution, but you want to build GHC using just a C compiler for idealogical reasons, you're slightly misguided :-) ---------- Let me describe some of the technical issues with getting GHC to build out of the box, with no GHC binary installed, on any platform. Hopefully this will provide some useful pointers to anyone out there with a burning desire to improve the GHC OOB experience. How could we achieve a platform-independent bootstrap? The only way I can see to do this is to have a set of completely platform-independent .hc files to bootstrap from. Then the general plan would be - bootstrap unregisterised to get a stage1 compiler. stage1 might be reduced functionality: no GHCi, perhaps no native code gen, no template haskell. - use this to build fully registerised libraries & stage2 To get our platform-independent .hc files, the contents of ghc/compiler ghc/lib ghc/utils libraries/base libraries/Cabal must all be compilable to platform-independent .hc code. That means - No platform #ifdefs in the Haskell code in these directories - No hsc2hs code in these directories We have to eradicate all platform #ifdefs, because they give rise to platform-varying .hc code. In practice, this will probably mean translating some code from Haskell to C. hsc2hs is a similar problem - that gives rise to platform-varying .hs code. Fortunately there is very little hsc2hs code left in here - it gives rise to other porting problems so we removed it. Our job is slightly easier: - As long as we still compile via-C, we can omit the native code generator in stage1, and build it in stage2 only. That's a big source of #ifdefs we don't have to worry about (arguably we should just compile in all the variants of the NCG anyway). However, our job is harder because - ghc/compiler/main/Constants.hs contains a bunch of baked-in constants such as the platform word-size. These would have to be made dynamic - or at least turned into unsafe reads of an external C variable. Given that a majority of the #ifdefs are Unix-vs-Windows, we could consider a partial solution, and settle for having two sets of .hc files, one for Unix and one for Windows. We could further split the Unix camp into 32-bit and 64-bit Unix, which makes the job even easier (the Constants.hs problem partly goes away). A few very rough figures: - total platform #ifdefs in the relevant sources: 395 - after omitting the native code gen: 148 - after omitting Windows: 28 - after omitting GHCi: 21 and there are 3 .hsc files in libraries/base, but they aren't necessary for bootstrapping. Hmm, it's starting to look plausible. Constants.hs is the biggest sticking point, and then hacking up the build system to do bootstrapping. Hope this has been of use to someone... Cheers, Simon

1 0