GHC and Haskell-Platform on OpenBSD
Hi, I'd like to know wether anyone here is using GHC on OpenBSD *and* relying on the Haskell-Platform meta package for OpenBSD. If there's no need for the HP meta package, I could just start to update GHC and all related packages for OpenBSD, but if there are a lot of people who prefer to stick to the HP, I'd to wait until the official update of the HP. So, if you love running pkg_add haskell-platform on OpenBSD, please speak up. And if you don't care an just run pkg_add ghc please speak up too ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Hi, On Tue, Nov 27, 2012 at 08:15:59PM +, Ian Lynagh wrote: Regarding Question 7 (enable dynamic by default on other platforms) and OpenBSD: as long as it's easy to disable it again, I'll be happy with *any* decision. It will be easy to turn it off, but depending on the platform we might have removed support for GHCi when it's turned off. Does ghci work for you currently? Yes, but I'm still at ghc-7,4.2. Not enough time to catch up with recent ghc development :-( Is this a registerised or unregisterised build? Registerised, working on i386 and amd66 (or x86 and x86_64 in the non-bsd-world). That's partially because currently we've even a patch explicitely disabling shared library support in our ports/packages system (last time I tried with shared lib support, I got some segfaults in the midst of the build, and unfortunately I'm still too short of time to debug/fix it). That's a bit bizarre. With shared libraries enabled, there still won't be any dynamically linked programs actually run. No worry. There were a lot of changes in OpenBSD during the last 6 months (including dl.so, pthreads, whatever). Wether there's a bug in the GHC build system, or in the (heavily patched) OpenBSD port, or in the binaries we use for bootstrapping, I really dont't know. I wouldn't ve surprised if it's some breakage on my side (with the bootstrappers i supply). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: renamed GMP symbols in GHC
On Wed, Jan 04, 2012 at 12:31:23PM +, Joachim Breitner wrote: One potential problem is that some Linux distributions really don't like it if you bundle modified versions of external libraries. However, I just don't see a way around this: [...] [...] I guess this means me... Indeed Debian has the policy to avoid modified bundled libraries, if somehow possible. For example, we patch the build system to use the system-provided libffi. This policy isn't even specific to linux distributions ;-) I don't know about the package building infrastructure for debian or fedora, but for openbsd (where i'm doing a lot of haskell stuff), it would be enough if the ghc sources would include not only a (patched or unpatched) gmp source tree but also the ghc-specific patches to gmp. The rationale behind this polcicy (for openbsd, i can't speak for debian): if there are 42 packages where the source distribution files contain their own (probably patched) version of gmp, and suddenly a critical patch has to be applied to gmp, we would have to apply it 43 times (for gmp itself and for all the 42 packages using a bundled gmp). If the source distribution files contained diffs for gmp, we could (at least try to) extract our patched gmp and apply the diff on top of it. = less work, any openbsd-specific patch automatically will be applied to all 42 packages. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Completely reproducible Haskell builds
On Fri, May 27, 2011 at 04:35:17PM +0100, Simon Marlow wrote: Next best idea is to make GHC use repeatable temporary .c .o file names for each invocation. There is already a unique temporary directory where all the the temporary files are created. This suggests I do not need to worry about adversarial races. So GHC just need to avoid racing with itself. I see a couple of options: 1) newTempName should create a new subdirectory for each call and the return a fixed name inside of this (so /tmp/ghc28016_0/ghc28016_0.c above would become /tmp/ghc28016_0/0/dummy.c) 2) mkExtraCObj could compute some hash function of its xs argument (C program text) and then create a file named, e.g. /tmp/ghc28016_0/38eb8d8eb0abe9c828ba60983e2a97f7a069ec41.c Which of these two looks better? Other ideas? The first is easier, and would be fine with me. An alternative could be to just strip the single `symbol' off the object file (using something like strip -N ...). I didn't yet test this for real. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote: I still have to find my noticeses about wether cBooterVersion affects more than only the ghc lib. Did a quick test the other day; bootstrapping ghc-7.0.3 from ghc-6.12.3 with two different VERSION_DATE files. The only visible change was in the ghc library, so this part indeed isn't worth any work. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Wed, Apr 06, 2011 at 12:40:45PM +0100, Ian Lynagh wrote:
compiler/stage2/build/Config.hs includes cBooterVersion, so if you boot
with a different version then you get different code = different ABI.
We could just remove this. In theory, stage2 won't be affected by the
bootstrapping compiler at all anyway.
Alternatively, if we make a config file (as we were discussing for
putting the paths to gcc and ar in) then it could go in there, and then
wouldn't be part of the ABI.
Even if Simon prefers the config file approach (and there's still
the question wether the booter version is useful at all), attached
is an old patch in darcs format i found on my disk (dated april
24th 2010). Just in case anyone wants to play with it.
I still have to find my noticeses about wether cBooterVersion affects
more than only the ghc lib.
Ciao,
Kili
1 patch for repository http://darcs.volkswurst.de/ghc-6.12/ghc:
Sat Apr 24 20:46:21 CEST 2010 Matthias Kilian k...@outback.escape.de
* Zap cBooterVersion, in an attempt to fix #4012
Note: this is obviously just a workaround, not a real fix.
New patches:
[Zap cBooterVersion, in an attempt to fix #4012
Matthias Kilian k...@outback.escape.de**20100424184621
Ignore-this: 18bf356e798b3c26bd4c8d2f2bc79789
Note: this is obviously just a workaround, not a real fix.
] {
hunk ./compiler/ghc.mk 50
@echo cProjectVersionInt= \$(ProjectVersionInt)\ $@
@echo cProjectPatchLevel:: String $@
@echo cProjectPatchLevel= \$(ProjectPatchLevel)\ $@
- @echo cBooterVersion:: String $@
- @echo cBooterVersion= \$(GhcVersion)\ $@
@echo cStage:: String $@
@echo cStage= show (STAGE :: Int) $@
@echo cIntegerLibrary :: String $@
hunk ./compiler/main/DynFlags.hs 2419
compilerInfo :: [(String, Printable)]
compilerInfo = [(Project name,String cProjectName),
(Project version, String cProjectVersion),
-(Booter version, String cBooterVersion),
(Stage, String cStage),
(Have interpreter,String cGhcWithInterpreter),
(Object splitting,String cSplitObjs),
hunk ./ghc/Main.hs 646
do hPutStr stderr Glasgow Haskell Compiler, Version
hPutStr stderr cProjectVersion
hPutStr stderr , for Haskell 98, stage
- hPutStr stderr cStage
- hPutStr stderr booted by GHC version
- hPutStrLn stderr cBooterVersion
+ hPutStrLn stderr cStage
-- We print out a Read-friendly string, but a prettier one than the
-- Show instance gives us
}
Context:
[Fix the GHC API link in the main doc index.html
Ian Lynagh ig...@earth.li**20100422213226]
[Set RELEASE to NO
Ian Lynagh ig...@earth.li**20100422160416]
[Fix Trac #3950: unifying types of different kinds
simo...@microsoft.com**20100412151845
Ignore-this: d145b9de5ced136ef2c39f3ea4a04f4a
I was assuming that the unifer only unified types of the
same kind, but now we can defer unsolved constraints that
invariant no longer holds. Or at least is's more complicated
to ensure.
This patch takes the path of not assuming the invariant, which
is simpler and more robust. See
Note [Mismatched type lists and application decomposition]
]
[Fix Trac #3943: incorrect unused-variable warning
simo...@microsoft.com**20100412151630
Ignore-this: 52459f2b8b02c3cb120abe674dc9a060
In fixing this I did the usual little bit of refactoring
]
[Convert boot and boot-pkgs to perl
Ian Lynagh ig...@earth.li**20100415143919
This stops us having to worry about sh/sed/... portability.
]
[Use $(MAKE), not make, when recursively calling make
Ian Lynagh ig...@earth.li**20100415121453]
[Update the user guide so it talks about the newer do rec notation everywhere
Ian Lynagh ig...@earth.li**20100416205416
Some of the problems highlighted in trac #3968.
]
[Fix typo
Ian Lynagh ig...@earth.li**20100416205412]
[Implement try10Times in Makefile
Ian Lynagh ig...@earth.li**20100420165909
Avoid using seq, as FreeBSD has jot instead.
]
[Give the right exit code in darcs-all
Ian Lynagh ig...@earth.li**20100421171339
Our END block was calling system, which alters $?. So now we save and
restore it.
]
[TAG old-time 1.0.0.4 release
Ian Lynagh ig...@earth.li**20100422124334]
Patch bundle hash:
fcf362722a7a7aa3c874e458349988857690c5e4
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote: Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Changing the bootstrapping compiler changes the ABIs. The same can happen if you interrupt and restart the build. http://hackage.haskell.org/trac/ghc/ticket/4012 Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc changes interface hashes?
On Tue, Apr 05, 2011 at 08:51:52PM +0100, Simon Marlow wrote: On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote: Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Changing the bootstrapping compiler changes the ABIs. The same can happen if you interrupt and restart the build. In general changes can creep in randomly, there's no direct link between changing the bootstrap compiler and getting different compilation results (as far as I know), but there are some small elements of randomness. Oh, I confused those two problems again :-( But memories come back, and IIRC the problem with the bootstrapping compiler is caused by the Booter version (as printed by ghc --info) passed up to the stage2 compiler. Wasn't the plan (about a year ago) to remove this? If time permits, I'll send a patch in a few days, but I first have to follow the switch to git, and I also want to update our (OpenBSDs) ports to ghc-7.0.3 and hp-2011.2. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
System.Posix.Signals weirdness
Hi, I'd expect the following program (compiled with ghc and without any specieal flags) to produce Just (Exited ExitSuccess) True but it produces Just (Exited ExitSuccess) False on Debian Lenny (ghc-6.8), OpenBSD-current (ghc-6.12.3), OpenBSD-current (ghc=7.0 from the 7.0 branch). module Main where import Data.IORef import System.Posix.Process import System.Posix.Signals import System.Posix.Unistd main = do caughtCHLD - newIORef False installHandler sigCHLD (Catch $ writeIORef caughtCHLD True) Nothing pid - forkProcess $ sleep 2 return () s - sleep 8 getProcessStatus False False pid = print readIORef caughtCHLD = print The sigCHLD handler is never called in this program. Is this expected behaviour? If so, why? Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.2 Release Candidate 1
Hi, On Thu, Dec 16, 2010 at 06:36:55PM +, Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 7.0.2: http://www.haskell.org/ghc/dist/7.0.2-rc1/ Some random notes for OpenBSD: - No close look at the test suite results yet, but at least I didn't notice any strangeness like the threading problems back in ghc-6.12. - BTW: it would be nice if snapshot sources or at least release candidate sources would also contain a tarball of the testsuite. I don't know about other distributors, but at least for OpenBSD we're including the testsuite into the files to download; I rolled my own testsuite-7.0.1.20101215.tar.bz2 from the darcs repo, but that's a little bit inconvenient ;-) - After working on updates of several Haskell packages and programs in the OpeNBSD ports tree, I didn't notice anything bad (at least not related to GHC). No strange compiler errors, no strange threading problems (as we had with early ghc-6.12 versions). - Probably a stupid one: the module list in .../html/libraries/index.html) is completely empty. This may be (and probably is) some breakage local to my machine, but: is anyone else seeing this? Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fixing LDAP lib compilation on OpenBSD
On Sat, Oct 30, 2010 at 07:28:40PM +0200, Julien Dessaux wrote: I'm using the LDAP lib for one of my projects and I found a problem while building it on an OpenBSD system. It wouldn't compile because there is a macro named differently in the ldap.h include file. Under linux, this macro is named LDAP_X_PROXY_AUTHZ_FAILURE but on OpenBSD (and probably other BSD flavours), it's named LDAP_PROXY_AUTHZ_FAILURE. I attached the diff I wrote in order to compile the lib on OpenBSD, but it's not a patch I can submit cause it now won't compile on Linux. How can I amend this in order to have a code that would compile on both systems? How is it possible to specify such conditional system dependent stuff for a C binding? You can use different CC-Options in LDAP.cabal depending on the OS. For example if os(openbsd) CC-Options: -DLDAP_X_PROXY_AUTHZ_FAILURE=LDAP_PROXY_AUTHZ_FAILURE else CC-Options: -DLDAP_DEPRECATED=1 Or, if LDAP_X_PROXY_AUTHZ_FAILURE is only used on Linux, just do it reverse, i.e. patch the sources to use LDAP_PROXY_AUTHZ_FAILURE and conditionally define it as LDAP_X_PROXY_AUTHZ_FAILURE on Linux; whatever fits better. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1
On Fri, May 28, 2010 at 10:05:36PM +0100, Simon Marlow wrote: hReady002(ghci) == did not investigate yet. failure details below This one is a known failure right now (I need to clean it up). Good to know. Thanks for the info. num009(normal,optc,hpc,optasm,ghci) == no idea. failure details below Suspicious... If in doubt, suspect OpenBSD here; this is not the first time I've seen strange differences between our math and the math on other systems. But it's reall strange that there are different failures for different ways. I'll try to find what's going on. signals002(normal,optc,hpc,optasm,ghci) == wrong exit code (150, expected 0). not yet investigated. Could be that signals are being delivered too quickly and overflowing the IO manager's pipe. We see this failure on our x86/Linux box too, but not on x86_64. Summary: if it's lost signals due to the pipe filling up, it's a known issue. Also good to know. I'll have a closer look wether it's the problem you mention (but I'm still short of time, so this may have to wait). As always, please don't let any problems specific to OpenBSD delay your release. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1
On Sun, May 23, 2010 at 07:42:21PM +0100, Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 6.12.3: [...] Please test as much as possible; bugs are much cheaper if we find them before the release! Here are some test results on OpenBSD/amd64, with an 800 MB data size liimit and with pthread support disabled (several people had serious trouble with pthread support enabled for ghc-6.12.2, so I disabled it in our port until I've time to debug that problem). I've used the ghc-6.12 branch from the darcs repository for it; a build with the official release candidate (plus the --with-gmp-* patch recently pushed) is still running. Executive summary: looks quite good. The only failure that *really* puzzles me is the num009 one. I've added some remarks to the list of unexpected failures below. OVERALL SUMMARY for test run started at Thu May 27 19:11:36 CEST 2010 2383 total tests, which gave rise to 7689 test cases, of which 0 caused framework failures 1605 were skipped 5872 expected passes 178 expected failures 0 unexpected passes 34 unexpected failures Unexpected failures: concprog001(ghci) == out of memory (probably harmless) getUserEntryForName(normal,optc,hpc,optasm,ghci) == known (by me) issue. probably a bug/incompatibility in OpenBSD hClose003(normal,optc,hpc,optasm,ghci) == did not investigate yet. failure details (for the normal way) below hReady002(ghci) == did not investigate yet. failure details below num009(normal,optc,hpc,optasm,ghci) == no idea. failure details below openFile008(normal,optc,hpc,optasm,ghci) == too many open files. limits were too tight on my system, I'll have to retest with higher limits queryfdoption01(normal,optc,hpc,optasm) == unsupported operation. rings a bell here, I'll look at it next weekend signals002(normal,optc,hpc,optasm,ghci) == wrong exit code (150, expected 0). not yet investigated. simpl015(optc,optasm) == out of memory (in the compiler). (probably harmless) testblockalloc(normal) == out of memory. (probably harmless) Details: = hClose003(normal) 1002 of 2383 [0, 1, 0] cd ./lib/IO '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o hClose003 hClose003.hs -package unix hClose003.comp.stderr 21 cd ./lib/IO ./hClose003/dev/null hClose003.run.stdout 2hClose003.run.stderr Actual stdout output differs from expected: --- ./lib/IO/hClose003.stdout.normalisedThu May 27 19:35:14 2010 +++ ./lib/IO/hClose003.run.stdout.normalisedThu May 27 19:35:14 2010 @@ -1,4 +1,4 @@ Right () False -Left file descriptor: X: hClose: resource vanished (Broken pipe) +Right () False *** unexpected failure for hClose003(normal) = hReady002(ghci) 1015 of 2383 [0, 6, 0] cd ./lib/IO sleep 1 | '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output hReady002.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS hReady002.genscript 1hReady002.interp.stdout 2hReady002.interp.stderr Actual stderr output differs from expected: --- /dev/null Thu May 27 19:35:59 2010 +++ ./lib/IO/hReady002.run.stderr.normalisedThu May 27 19:35:59 2010 @@ -0,0 +1 @@ +hReady002: stdin: hWaitForInput: end of file *** unexpected failure for hReady002(ghci) = num009(normal) 1072 of 2383 [0, 12, 0] cd ./lib/Numeric '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o num009 num009.hsnum009.comp.stderr 21 cd ./lib/Numeric ./num009/dev/null num009.run.stdout 2num009.run.stderr Actual stdout output differs from expected: --- ./lib/Numeric/num009.stdout.normalised Thu May 27 19:39:12 2010 +++ ./lib/Numeric/num009.run.stdout.normalised Thu May 27 19:39:12 2010 @@ -1 +1,6 @@ +tanf +-Infinity +NaN +(-8388608,105) +(-12582912,105) Done *** unexpected failure for num009(normal) = num009(optc) 1072 of 2383 [0, 13, 0] cd ./lib/Numeric '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o num009 num009.hs -O -fvia-C num009.comp.stderr 21 cd ./lib/Numeric ./num009/dev/null num009.run.stdout 2num009.run.stderr Actual stdout output differs from expected: --- ./lib/Numeric/num009.stdout.normalised Thu May 27 19:39:13 2010 +++ ./lib/Numeric/num009.run.stdout.normalised Thu May 27 19:39:13 2010 @@ -1 +1,6 @@ +tanf +NaN +NaN +(-12582912,105) +(-12582912,105) Done *** unexpected failure for num009(optc) = num009(hpc) 1072 of 2383 [0, 14, 0] cd ./lib/Numeric '/home/kili/src/ghc/ghc-6.12/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -o num009
Re: Output character encoding for ghc on OpenBSD
On Mon, Apr 19, 2010 at 02:57:00PM +0100, Simon Marlow wrote: A few of the tests in the test suite assume a UTF-8 locale, so you're probably falling foul of that. We could fix the tests - but we do want to test that the locale encoding is being respected in some way, so just adding hSetEncoding to those tests would be wrong. Nah, don't touch the tests because of this. For the IO library, I expect you should default the encoding to Latin-1 on OpenBSD. I've some (rather horrible) patch that tries to make sense out of LC_ALL or LC_CTYPE if set. And if it isn't set, I'm currently defaulting to 646//TRANSLIT (which is ASCII with translation of some non-ASCII characters to ASCII art, like `(c)' for \xa9). But Latin-1 may be a more usable default. Thanks for the suggestion. (No, I'm not going to send this patch to cvs-ghc, it's really too horrid). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Output character encoding for ghc on OpenBSD
Hi, as some of you may know, I'm working on an update of OpenBSDs ghc port to 6.12.2, currently chasing down the last remaining testsuite failures. Yesterday, I ran into a problem which I have a fix for, but only a really ugly fix, and I need some opinions of what users would prefer. The problem is that Haskell uses unicode characters internally (ghc itself uses UTF-32 internally, where the endianess depends on the architecture it's running on), and that any Haskell program (including ghc and ghci) has to convert between the internal representation and the actual locale settings of the system it's running on. Unfortunately, OpenBSD is really bad if it comes to locale support; the only supported locales are the C and the POSIX locales, so even if you set LC_ALL or LC_CTYPE to something like, for example, de_DE.iso88591, this would have no effect on OpenBSD. Anyway, the short story is that I have to either hard-code the character set to something like utf-8, or ghc will start to behave really strange (for example, ghci would terminate immediately if you just *type* a non-ASCII character). So what would you prefer? - Use utf-8 and only utf-8 (i.e. hardcoded)? - Use something like iso-8859-15 (hardcoded)? - Make it configurable via some non-standard environment variable (GHC_CODESET, for example). If so, what should be the default if the environment variable isn't set? Back to 7 bit (ASCII)? utf-8? Some of the latin variants? Your suggestions are appreciated. Thanks in advance. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Output character encoding for ghc on OpenBSD
Hi,
On Sun, Apr 18, 2010 at 10:53:22AM -0700, Judah Jacobson wrote:
Anyway, the short story is that I have to either hard-code the
character set to something like utf-8, or ghc will start to behave
really strange (for example, ghci would terminate immediately if
you just *type* a non-ASCII character).
That sounds like it might be something to do with the haskeline
package, which ghci uses for user interaction. Haskeline makes its
own FFI calls to translate raw input bytes into Unicode Chars.
Oh, this may indeed be a second problem. However, the encoding
problem itself also manifests in the `openTempFile001' test of the
testsuite. For example, with an unpatched ghc-6.12, the test fails
with the following output:
= openTempFile001(normal) 1048 of 2375 [0, 38, 0]
cd ./lib/IO '/usr/obj/ports/ghc-6.12.2/ghc-6.12.2/inplace/bin/ghc-stage2'
-fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output
-o openTempFile001 openTempFile001.hsopenTempFil
e001.comp.stderr 21
cd ./lib/IO ./openTempFile001/dev/null openTempFile001.run.stdout
2openTempFile001.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
openTempFile001: ./test22236.txt: hClose: invalid argument (Illegal byte
sequence)
*** unexpected failure for openTempFile001(normal)
Can
you elaborate further on what exactly the issue is with OpenBSD's
locale support? In particular, there's several components used by
Haskeline:
- call set_locale(LC_CTYPE)
Problem number 1: set_locale(LC_CTYPE) fails (i.e. returns NULL)
for any locale except `C` or `POSIX'. Did I mention that OpenBSD
is really bad with locales? ;-)
- call nl_langinfo(CODESET)
Always returns `646' (ASCII). Duh.
- pass the resulting string (which should be, e.g., $LANG) to iconv_open
iconv_open appears to need the *codeset* name, not a complete locale.
Note that OpenBSD uses GNU libiconv-1.13, which AFAIK differs from
the one included in glibc. Even worse, I have to pass something
like UTF-8, whereas UTF8 doesn't work.
- call iconv on user input (which may be malformed)
I wrote a little C program that does the following (some error
checks omitted here):
char *inp, outp;
size_t insz, outsz;
unsigned char in[] = {0xa9, 0, 0, 0};
char out[512];
inp = in;
outp = out;
insz = sizeof(in);
outsz = sizeof(out) - 1;
setlocale(LC_CTYPE, );
ic = iconv_open(, UTF-32LE);
if (iconv(ic, inp, insz, outp, outsz) == -1) {
... bail out (perror() etc.) ...
}
iconv_close(ic);
*outp = 0;
puts(out);
And it just doesn't work, regardless what I set LC_CTYPE to. The
only way to get it printing the copyright symbol is to explicitely
use UTF-8 (or ISO-8859-1 or something else that knows about
that symbol) as the first argument to iconv_open().
Is the problem that setting $LC_ALL or $LANG has no effect on the
string returned by nl_langinfo, so the translation fails?
Yes, see above.
If so,
haskeline is supposed to output ?s in that case, so there might be a
bug in the package.
It fails (or rather: ghci fails, since I didn't yet do any separate
haskeline tests) with the same error as the test mentioned above,
with the difference that it fails on hPutChar instead of hClose for
obvious reasons.
Finally, when you say you have to hard-code the character set, are
you talking about ghc, haskeline, the base library, or somewhere else?
I'm talking about libraries/base/GHC/IO/Encoding/Iconv.hs
See? There just is no non-hackerish way to fix this (except of
course improving locale support on OpenBSD, but that's beyond my
scope currently).
Ciao,
Kili
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.12.2 Release Candidate 1
On Fri, Apr 16, 2010 at 04:02:03PM +0900, Jens Petersen wrote: Just for the record let me report the following build failure for f14 (rawhide): http://koji.fedoraproject.org/koji/taskinfo?taskID=2107186 [...] I have reproduced this now also with ghc-6.12.1 inplace/bin/ghc-stage1 -prof -H32m -O-package-name base- ^ Here! -hide-all-packages -i -ilibraries/base3-compat/. [...] libraries/base3-compat/Data/IORef.hs:1:0: Bad interface file: libraries/base3-compat/dist-install/build/Prelude.p_hi Something is amiss; requested module base-:Prelude differs from name found in the interface file base-3.0.3.2:Prelude make[1]: *** [libraries/base3-compat/dist-install/build/Data/IORef.p_o] Error 1 make: *** [all] Error 2 [...] What should one make of Something is amiss; requested module base-:Prelude differs from name found in the interface file base-3.0.3.2:Prelude here when building ghc?? I don't know why, but for some reason something's going wrong with creating libraries/base3-compat/dist-install/package-data.mk, which *should* contain the correct version number (i.e. libraries/base3-compat_dist-install_VERSION = 3.0.3.2). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testing 6.12.2-pre
On Wed, Apr 14, 2010 at 08:44:29PM +0200, Matthias Kilian wrote: module Main(main) where import System.IO import System.Process main = do hin - openBinaryFile /dev/null ReadMode hp - runProcess /bin/ls [-l] Nothing Nothing (Just hin) Nothing Nothing r - waitForProcess hp print r IF I run this on OpenBSD (amd64), I get foo: /bin/ls: runProcess: unsupported operation (Operation not supported by device) I found it. I'll send a patch as soon as I've tested the fix. The neat thing is that darcs send probably doesn't work without the fix ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testing 6.12.2-pre
On Fri, Apr 09, 2010 at 05:48:17PM +0400, Serge D. Mechveliani wrote: I have tested ghc-6.12.1.20100330 on Debian Linux, i386-family, on the DoCon test, without profilig. It looks all right. Even if I reported to Ian that everything is fine on OpenBSD, I just found some strangeness with openBinaryFile and runProcess when testing darcs-2.4 built with the (still not really released) ghc-6.12.2. Here's a small test program: module Main(main) where import System.IO import System.Process main = do hin - openBinaryFile /dev/null ReadMode hp - runProcess /bin/ls [-l] Nothing Nothing (Just hin) Nothing Nothing r - waitForProcess hp print r IF I run this on OpenBSD (amd64), I get foo: /bin/ls: runProcess: unsupported operation (Operation not supported by device) Tracing the process shows the following hints (File handle 0x6 is the one from /dev/null): 25151 foo CALL ioctl(0x6,TIOCGETA,0x7f7e1da0) 25151 foo RET ioctl -1 errno 19 Operation not supported by device 25151 foo CALL fcntl(0x6,0x4,0x4) 25151 foo RET fcntl -1 errno 19 Operation not supported by device I'm not sure about the ioctl call, but the fcntl tries to set the handle to nonblocking mode. There's already some comment about this (on FreeBSD) in the code, but I'm unsuere what exactly to do about it. I'd really like to see the result of this program on FreeBSD and/or NetBSD, so we know wether it's specific to OpenBSD or wether it happens on all BSD-like systems. Ciao, Kili ps: GHC guys, please don't let this stop you from going on with the ghc-6.12.2 release process. Problems like this can be easily fixed by package maintainers. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross-compiling ghc to openbsd
On Fri, Jan 29, 2010 at 06:10:52PM +0100, Nicolas Martyanoff wrote: I'm trying to cross-compile GHC as follows: Host: Linux, x86_64, GHC 6.12.1 Target: OpenBSD 4.6 stable, i386 IMHO, you shouldn't go that way, because it adds much more complexity than you already have with OpenBSD as host *adn* target. During my last tests back in december, not even OpenBSD/i386 - OpenBSD/i386 worked with .hc files. That should be fixed first. Then, something like OpenBSD/i386 - OpenBSD-amd64 (and vice versa) should be done. And if this works, it's questionable wether one should work on cross building with .hc files using differen host an target operating systems or wether it would be more useful to start getting GHC running on other OpenBSD archs. I follow the guide at: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran the following commands: export AUTOCONF_VERSION=2.62 export AUTOMAKE_VERSION=1.9 cp /bin/pwd utils/ghc-pwd/ghc-pwd sh boot ./configure --enable-hc-boot --build=i386-unknown-openbsd --host=i386-unknown-openbsd --target=i386-unknown-openbsd [...] IIRC there where some discussions (or even patches pushed?) about the build/host/target combo, so you may try to pull ghc sources with darcs (head or the 6.12 branch). The latest fails, with the following trace: http://pastebin.ca/1770926 The following errors are quite interesting: includes/stg/Types.h:103:2: #error GHC untested on this architecture: sizeof(void *) != 4 or 8 includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P Your build is (re)creating includes/ghcautoconf.h -- this looks very wrong to me, since ghcautoconf.h is supposed to be created by a former configure / make bootstrapping-files on the target platform and then used on the host for creating the .hc files. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross-compiling ghc to openbsd
On Fri, Jan 29, 2010 at 09:42:27PM +0100, Nicolas Martyanoff wrote: This probably means some type identifier used at that point hasn't been declared, or macro defined or whatever. You'd have to see what it is, and maybe it will be more obvious what went wrong. It seems that SIZEOF_VOID_P isn't defined anywhere. It's defined in includes/ghcautoconf.h (which is created during configure and make bootstrapping-files on the target platform). All right, I'll try again with the last darcs version when I get access to a i386 Linux machine. You don't need any linux machine for this. The current darcs port for OpenBSD may be a little bit outdated, but it still works. In the mean time, I'll try to run a GHC 6.6 - 6.10 - 6.12 build chain, 6.6 being the latest version available in OpenBSD's ports. I sent you a (admittedly horrible) script to do this chain. Use it. If it doesn't work, sent complaints. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running GHC 6.10.* on OpenBSD
On Sat, Dec 12, 2009 at 05:30:44AM +0200, Thanos Tsouanas wrote: Up to now I've only used binary versions of GHC, but since my operating system's (OpenBSD) version of GHC is lagging behind (currently at 6.6.1), I need to update it. I tried using my system's ghc-6.6.1 to compile ghc-6.10.4 but it failed due to haskeline not being installed (and trying to install it also failed). I don't know wether the release tarball contains haskeline, but you could always download the sources via darcs and use the darcs-all script from the ghc tree to fetch all necessary libraries. Here are some scripts I'm using to build all kinds of ghc versions (6.10, 6.12, head, bootstrapping stuff etc.): http://darcs.volkswurst.de/build/ You may have to edit the scripts for your purposes. Or just wait for an update of the port ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running GHC 6.10.* on OpenBSD
On Sat, Dec 12, 2009 at 09:22:56AM +0100, Karel Gardas wrote: I somehow managed to first install everything what's required on system provided 6.6.1 to compile 6.10. I'm not sure if I went step by step 6.6.1-6.8.3-6.10.3 as you try. No need for 6.8, you can build 6.10 straight with 6.6. IMHO cross-compilation is no go in this case since I hope I'm right assuming this is not supported in 6.10, but was fixed in 6.12 again. Kind of. There are still issues with *real* porting to other platforms (#3472, probably more), but it's possible to create hc bootstrapping filesets and use them to bootstrap on the same platform. Even if this sounds kind of useless, it'll help a lot updating the OpenBSD port. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running GHC 6.10.* on OpenBSD
On Sat, Dec 12, 2009 at 03:29:09PM +0200, Thanos Tsouanas wrote: No need for 6.8, you can build 6.10 straight with 6.6. Ok, I guess I didn't try hard enough.. Probably just --with-iconv-includes=/usr/local/include \ --with-iconv-libraries=/usr/local/lib missing to ./configure. Everything else should work fine nowadays. IMHO cross-compilation is no go in this case since I hope I'm right assuming this is not supported in 6.10, but was fixed in 6.12 again. Kind of. There are still issues with *real* porting to other platforms (#3472, probably more), but it's possible to create hc bootstrapping filesets and use them to bootstrap on the same platform. Even if this sounds kind of useless, it'll help a lot updating the OpenBSD port. Then it's worth a shot. How would I create those hc bootstrapping filesets? Using the system's ghc-6.6.1? If all you want is a working ghc-6.10, please don't waste your time with bootstrapping filesets. Just use ghc-6.6.1 and build ghc-6.10 from it (and, if you want to, build ghc-6.12 from ghc-6.10). BTW: if you're using my scripts, you'll probably also have to install (apart from ghc-6.6.1) alex, darcs, gmake, haddock, happy, hscolour and python (version 2.5). All available as precompiled packages for OpenBSD (amd64 and i386). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling to ANSI C
On Sun, Nov 08, 2009 at 10:19:26AM +0300, Bulat Ziganshin wrote: seems that wizards are on holiday ATM, so i will help a little - ghc ports are divided into registerized (working with cpu registers) and unregisterized (just a C code generated). I wouldn't touch the *registerized* variant using intermediate C files, because that means you probably would also have to modify the evil mangler, which is -- evil. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: no-Haddock GHC build
On Tue, Sep 22, 2009 at 07:34:53AM -0700, Donn Cave wrote: I'm thinking it would be expedient to omit Haddock while building a ghc 6.11 snapshot, per bug ticket #3531 From my basic understanding of its purpose there, that ought to work out fine - I mean, not to undervalue documentation, but the compiler should be able to function without it. But not well versed in the intricacies of the GHC build, so please set me straight if I'm about to waste a lot of time untangling it in the makefiles. I sent a patch for this to cvs-ghc@: http://www.haskell.org/pipermail/cvs-ghc/2009-September/050255.html I wasn't even aware of that ticket ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue.
On Thu, Sep 17, 2009 at 09:17:35AM +0100, Simon Marlow wrote: Glad you got it going. I notice there are a few test failures, many of which could be fixed easily, e.g. --- ./lib/IO/hClose002.stdout.normalisedWed Sep 16 14:08:09 2009 +++ ./lib/IO/hClose002.run.stdout.normalisedWed Sep 16 14:08:09 2009 @@ -1,4 +1,4 @@ -Left hClose002.tmp: hClose: invalid argument (Bad file descriptor) +Left hClose002.tmp: hClose: invalid argument (Bad file number) Right () Right () Right () *** unexpected failure for hClose002(normal) that just needs a platform-specific expected output file (hClose002.stdout-i386-unknown-solaris2). BTW: is there an easy way to do some general output filtering on *all* tests for different platforms? It may not be helpful for the above test, but for some differences (like stderr in case of several types of core dumps on different operating systems, or the typical linker warnings about strcat(3), strcpy(3) etc. on OpenBSD) it may be less maintainance work to filter or modify the output on specific platforms. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue.
On Wed, Sep 16, 2009 at 10:23:58AM +0200, Karel Gardas wrote: Before going to trace anything I've compared sparky and my setup and it seems I've had forgotten libiconv library in /usr/local/lib and LD_LIBRARY_PATH contained this lib. So I've modified LD_LIBRARY_PATH to exclude /usr/local/lib and now surprisingly base configure fails with: checking for library containing iconv... no configure: error: iconv is required on non-Windows platforms make[1]: *** [libraries/base/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 Running the build bot with ICONV_INCLUDE_DIRS=/usr/local/include ICONV_LIB_DIRS=/usr/local/lib in the environment fixes the iconv problems, at least on OpenBSD. (I need some more environment tweaks but that's really related to my OS) Ciao, Kili -- Manch Massenmörder macht auch immer mal gern einen Abstecher. -- Dieter Brügmann in dtjd, 20.2.2001 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Plans for GHC 6.12.1: release candidate 14 September 2009
On Tue, Aug 18, 2009 at 03:03:43PM +0100, Ian Lynagh wrote: This is a summary of our plans for GHC 6.12.1. We are aiming to have the first release candidate out on the 14th September 2009. Until then, we plan to focus on the bugs in the 6.12.1 milestone, marked high priority; they are listed here: http://hackage.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedpriority=highestpriority=highmilestone=6.12.1order=priority Would it be better if I break my stable build slave in favor of the head build slave then? IIRC, I've to tweak some environment variables to make head build again, but it would break the stable builds. Ciao, Kili -- _|_ is pronounced 'bottom', and is the greatest lower bound of a complete lattice. -- Nick Williams in comp.lang.functional ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: use gtar and not tar under solaris
On Thu, Aug 06, 2009 at 12:30:51PM +0100, Duncan Coutts wrote: I've just been informed that unpacking the binary (i386) solaris distribution using bunzip2 and tar: It may work better in future if you use a non-GNU tar to pack it up in the first place. GNU tar uses a non-standard tar format by default. Solaris tar would likely have more luck unpacking a POSIX/USTAR tar format file. It's also possible to use gnu tar to make standard tar format files, using --format ustar rather than gnu tar's default of --format gnu. Is there something like pax(1) available on solaris? If so, it should be be preferred, because it's a POSIX tool, so there's some hope that it behaves the same on different systems. pax(1) should be available on all BSD systems, and to my knowledge, there's a pax package available at least for Debian Linux. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: use gtar and not tar under solaris
On Thu, Aug 06, 2009 at 08:54:49PM +0200, Christian Maeder wrote: Is there something like pax(1) available on solaris? If so, it should be be preferred, because it's a POSIX tool, so there's some hope that it behaves the same on different systems. Yes, pax is available under solaris. I thought GNU tar is the standard packer under unix. Depends on what `standard' means ;-) - tar has been there forever on unices, with several slightly incompatible format extensions - GNU tar is just another implementation, typically used on Linux, and it has its own incompatible format extensions. - pax is (or should be) available everywhere, its behaviour is defined by POSIX, it should (by default) create archives readable by most tar implemenations, but almost nobody knows about it ;-) http://www.opengroup.org/onlinepubs/9699919799/utilities/pax.html I wonder wether Duncan did read and understood that bit of documentation, I didn't even read all of it ;-) (The usage message of pax is less clear.) The manpage (and of course the POSIX definition) are hard stuff, too. However, to create an archive, you can use something like $ pax -wf foo.tar directory Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.10.3-prerelease failed build log for freebsd7.2
On Wed, May 06, 2009 at 08:48:04PM +0100, Ian Lynagh wrote: H Kili, On Mon, May 04, 2009 at 09:36:00PM +0200, Matthias Kilian wrote: In your case, it doesn't find libiconv, thus isn't built, and causes failure later. In my case (a buildbot running OpenBSD-4.5 on i386), the haskeline build itself fails (see `kili-stable' on darcs.haskell.org/buildbots), Is iconv installed somewhere on that machine? If so, where is it? (both the library and the header file) Binary in /usr/local/bin/iconv, library in /usr/local/lib, header in /usr/local/include. The strange thing isn't that it isn't detected correctly (linking is done a little bit differently on OpenBSD, you have to explicitely specify depending libs), but that the overall build doesn't fail on my fast build machine at home (which i still have to turn into a buildslave) Anyway, i'll look into this next weekend. Don't hold back the release because of this. For FreeBSD, there should be no problem to add some small patches (or probably just some additional arguments to configure), and for OpenBSD, ir just doesn't matter (because I'll wait for ghc 6.12 with our port). Ciao, Kili -- Automake and autoconf deserve to wither and die, but unfortunately noone at GNU seems to make much of an effort to euthanasize them. -- Han-Wen Nienhuys, on Lilypond-devel mailing list ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.10.3-prerelease failed build log for freebsd7.2
Hi, On Sun, May 03, 2009 at 11:03:49PM -0700, brad clawsie wrote: after some trying, i was unable to get the 6.10.3 prerelease to build on freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc. i saved the output of the entire build from ./configure to the point of failure. it is too long too attach here, you can see it at: http://www.b7j0c.org/ghc-6.10.3.log.txt Interesting. haskeline seems to break the build in different ways and at different places (and sometimes it doesn't fail at all). In your case, it doesn't find libiconv, thus isn't built, and causes failure later. In my case (a buildbot running OpenBSD-4.5 on i386), the haskeline build itself fails (see `kili-stable' on darcs.haskell.org/buildbots), but at the same time on OpenBSD-current on an amd64 the haskeline build complains about a missing libiconv but builds nevertheless. This all is a little bit confusing, but it should be fixable by telling configure where to find libivonv (i didn't yet have the time to look what's going on for real here). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testsuite boot failure [was: Re: Solaris/x86 bot failing on stage2 haddock installation.]
On Sun, Jan 11, 2009 at 10:36:56PM +0100, Karel Gardas wrote: A fix from Conal Elliott has already been pushed by Ian. Indeed! Now compilation aborts on booting testsuite with following output: make: Entering directory `/buildbot/ghc/kgardas/build/testsuite' make: *** No rule to make target `boot'. Stop. make: Leaving directory `/buildbot/ghc/kgardas/build/testsuite' This is strange: $ darcs changes --last=1 Sat Jan 10 22:42:04 CET 2009 Ian Lynagh ig...@earth.li * Add a boot target, and tidy up the Makefile a bit Yet the file in question (testsuite/mk/test.mk) isn't included by testsuite/Makefile nor testsuite/mk/boilerplate.mk. Did I ever complain about how broken the ghc build system is? ;-) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: pthread mutex error building 6.10 on NetBSD
Hi,
On Thu, Jan 01, 2009 at 11:46:31AM +0100, Matthias Kilian wrote:
pthread_mutex_unlock() is called, evidently from fileLock(), with an
invalid mutex.
NetBSD's pthread implementation differs from Linux in its intolerance
of such things. I have found errors where someone forgets that a mutex
was never used and tries to unlock it. I guess you could do that all day
long on Linux without noticing anything, but NetBSD aborts the program.
In the present case, I don't see anything like that wrong in rts/FileLock.c,
though. I'm stumped.
So I'm checking, has anyone else built 6.10 on NetBSD?
Could you (and anyone else on any operating system using pthreads)
please try to build with the patch below? It checks the return
values of pthread_mutex_lock() and pthread_mutex_unlock() by default
(even if DEBUG isn't defined) and contains some other uncluttering.
Seems to work fine here on OpenBSD (for ghc-head), but before I
send out a darcs patch, I'd like to see some results on other
systems.[1]
Of course, the patch won't fix the problem for NetBSD, but it may
give some more hints.
Ciao,
Kili
[1] and if you insist in darcs patches, just pull from
http://darcs.volkswurst.de/users/kili/ghc-6.10/ghc/ or
http://darcs.volkswurst.de/users/kili/ghc/
diff -x _darcs -rNup ../ghc/includes/OSThreads.h ./includes/OSThreads.h
--- ../ghc/includes/OSThreads.h Sun Jan 4 22:28:46 2009
+++ ./includes/OSThreads.h Sun Jan 4 22:11:34 2009
@@ -23,6 +23,7 @@
#else
#include pthread.h
+#include errno.h
typedef pthread_cond_t Condition;
typedef pthread_mutex_t Mutex;
@@ -34,47 +35,26 @@ typedef pthread_key_t ThreadLocalKey;
#define INIT_COND_VAR PTHREAD_COND_INITIALIZER
#ifdef LOCK_DEBUG
+#define LOCK_DEBUG_BELCH(what, mutex) \
+ debugBelch(%s(0x%p) %s %d\n, what, mutex, __FILE__, __LINE__)
+#else
+#define LOCK_DEBUG_BELCH(what, mutex) /* nothing */
+#endif
+/* Always check the result of lock and unlock. */
#define ACQUIRE_LOCK(mutex) \
- debugBelch(ACQUIRE_LOCK(0x%p) %s %d\n, mutex,__FILE__,__LINE__); \
- pthread_mutex_lock(mutex)
-#define RELEASE_LOCK(mutex) \
- debugBelch(RELEASE_LOCK(0x%p) %s %d\n, mutex,__FILE__,__LINE__); \
- pthread_mutex_unlock(mutex)
-#define ASSERT_LOCK_HELD(mutex) /* nothing */
-
-#elif defined(DEBUG) defined(linux_HOST_OS)
-#include errno.h
-/*
- * On Linux, we can use extensions to determine whether we already
- * hold a lock or not, which is useful for debugging.
- */
-#define ACQUIRE_LOCK(mutex) \
+ LOCK_DEBUG_BELCH(ACQUIRE_LOCK, mutex); \
if (pthread_mutex_lock(mutex) == EDEADLK) { \
barf(multiple ACQUIRE_LOCK: %s %d, __FILE__,__LINE__); \
}
+
#define RELEASE_LOCK(mutex) \
+ LOCK_DEBUG_BELCH(RELEASE_LOCK, mutex); \
if (pthread_mutex_unlock(mutex) != 0) { \
barf(RELEASE_LOCK: I do not own this lock: %s %d, __FILE__,__LINE__); \
}
#define ASSERT_LOCK_HELD(mutex) ASSERT(pthread_mutex_lock(mutex) == EDEADLK)
-
-#define ASSERT_LOCK_NOTHELD(mutex) \
- if (pthread_mutex_lock(mutex) != EDEADLK) { \
- pthread_mutex_unlock(mutex); \
- } else { \
-ASSERT(0); \
- }
-
-
-#else
-
-#define ACQUIRE_LOCK(mutex) pthread_mutex_lock(mutex)
-#define RELEASE_LOCK(mutex) pthread_mutex_unlock(mutex)
-#define ASSERT_LOCK_HELD(mutex) /* nothing */
-
-#endif
#endif // CMINUSMINUS
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: pthread mutex error building 6.10 on NetBSD
On Wed, Dec 31, 2008 at 10:44:07PM -0800, Donn Cave wrote:
I tried to build GHC 6.10.1 on NetBSD 4.0 this afternoon, and ran into
an error, where cabal-bin calls the stage2 ghc in utils/installPackage.
pthread_mutex_unlock() is called, evidently from fileLock(), with an
invalid mutex.
NetBSD's pthread implementation differs from Linux in its intolerance
of such things. I have found errors where someone forgets that a mutex
was never used and tries to unlock it. I guess you could do that all day
long on Linux without noticing anything, but NetBSD aborts the program.
In the present case, I don't see anything like that wrong in rts/FileLock.c,
though. I'm stumped.
So I'm checking, has anyone else built 6.10 on NetBSD?
Only on OpenBSD, and there it builds fine (when bootstrapping from
either ghc-6.6 or -6.10). But what's interesting is that in
includes/OSThreads.h the return values of pthread_mutex_lock(3) and
pthread_mutex_unlock(3) aren't checked except apparently on Linux
when building with DEBUG defined.
You could either try to build with LOCK_DEBUG defined, so you see
exactly when a lock is acquired and released, or try to build with
DEBUG defined and that ` defined(linux_HOST_OS)' removed from
OSThreads.h to see what's going wrong.
BTW: is there any pthread implementation still in the wild where
pthread_mutex_{,un}lock() does NOT indicate a deadlock by EDEADLK?
If not, the DEBUG part of OSThreads.h could be used for all systems,
not only Linux.
Ciao,
Kili
--
A typo a day, keeps the dictionnary away.
-- Miod Vallat
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking error during stage2
On Tue, Nov 11, 2008 at 06:38:02PM +0100, dermiste wrote:
I've successfully built GHC-6.10.1 from 6.6.1 on OpenBSD 4.4, and
would like now to generate a hc-file-bundle to build it without
pre-existing GHC. I followed the instructions in [1], but I'm stuck
with this error :
Linking dist-install/build/installPackage/installPackage ...
/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/unix/dist/build/libHSunix-2.3.1.0.a(Semaphore.o)(.text+0xac):
In function `unixzm2zi3zi1zi0_SystemziPosixziSemaphore_zdwa_info':
: undefined reference to `sem_trywait'
[...]
Obviously, the linker skips entirely /usr/lib/libpthread.a, as all the
symbols defined in semaphore.h are into it.
A quick hack I used for my work on ghc-6.8: just disable
System.Posix.Semaphore.
--- libraries/unix/System/Posix.hs.orig Sat May 3 19:25:32 2008
+++ libraries/unix/System/Posix.hs Sun May 18 14:37:13 2008
@@ -26,7 +26,6 @@ module System.Posix (
module System.Posix.Time,
module System.Posix.User,
module System.Posix.Resource,
- module System.Posix.Semaphore,
module System.Posix.SharedMem
) where
@@ -43,7 +42,6 @@ import System.Posix.Terminal
import System.Posix.Time
import System.Posix.User
import System.Posix.Resource
-import System.Posix.Semaphore
import System.Posix.SharedMem
{- TODO
--- libraries/unix/unix.cabal.orig Sat May 3 19:25:32 2008
+++ libraries/unix/unix.cabal Sun May 18 13:44:08 2008
@@ -32,7 +32,6 @@ exposed-modules:
System.Posix.User
System.Posix.Signals
System.Posix.Signals.Exts
-System.Posix.Semaphore
System.Posix.SharedMem
extra-source-files:
configure.ac configure
It's not a proper solution, but it may help for getting the build
a little bit farther (and OpenBSD doesn't support sem_open(3)
anyway).
Ciao,
Kili
--
It's a Barrier Of Entry issue: if you can't figure out which floppy
to boot from, go run Gentoo.
-- Matthew Jenove on [EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
On Mon, Sep 29, 2008 at 10:26:35PM +0200, Matthias Kilian wrote: A full test log is available at http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log Same for openbsd-amd64, built from sources pulled from the darcs repository at 15/Oct/2008:13:00:00 +0200: http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-amd64.log OVERALL SUMMARY for test run started at Wed Oct 15 21:07:08 CEST 2008 2252 total tests, which gave rise to 12108 test cases, of which 0 caused framework failures 2301 were skipped 8846 expected passes 128 expected failures 0 unexpected passes 833 unexpected failures And for ghc-head (pulled an hour later): http://openbsd.dead-parrot.de/ghctests/ghc-head-openbsd-amd64.log OVERALL SUMMARY for test run started at Thu Oct 16 12:36:23 CEST 2008 2252 total tests, which gave rise to 12108 test cases, of which 0 caused framework failures 2294 were skipped 8917 expected passes 128 expected failures 0 unexpected passes 769 unexpected failures Most failures are caused by ghci which is still broken for openbsd-amd64. Unfortunately, I don't have enough time to look at the other failures now. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
On Mon, Sep 29, 2008 at 10:46:34AM +0100, Ian Lynagh wrote: BTW: I had some problems running the testsuite some weeks ago, because some autoconf'd stuff was missing. When building from the repository (*not* from the source tarballs), are there any additional steps beyond sh boot ./configure --prefix=... gmake install required? I'm not sure if running gmake install without first running gmake works. Also, note that if you are building the extralibs then you need to run sh boot after getting them. I was sloppy in my mail. Actually I'm even building stage1 and stage2 explicitely before installing. From my script: nice time gmake stage1 nice time gmake stage2 nice time gmake install And my problem with the testsuite was a PEBKAC (of course): on OpenBSD, python is installed as python-2.3, python-2.4, python-2.5 (you can have several versions installed in parallel), which isn't found by configure, which in turn lets the testsuite bail out. Setting PythonCmd during configure fixed it. I've yet to evaluate the results of the testsuite. I'll post it in a few hours. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
On Mon, Sep 29, 2008 at 07:07:33PM +0200, Matthias Kilian wrote: And my problem with the testsuite was a PEBKAC (of course): on OpenBSD, python is installed as python-2.3, python-2.4, python-2.5 (you can have several versions installed in parallel), which isn't found by configure, which in turn lets the testsuite bail out. Setting PythonCmd during configure fixed it. I've yet to evaluate the results of the testsuite. I'll post it in a few hours. Summary (skipping all the details): OVERALL SUMMARY for test run started at Sun Sep 28 17:57:33 CEST 2008 2233 total tests, which gave rise to 12011 test cases, of which 0 caused framework failures 2244 were skipped 9324 expected passes 140 expected failures 20 unexpected passes 283 unexpected failures This looks more scary than it is; many unexpected failures are caused by a change in Rational formatin (17%42 vs. 17 % 42), some others are probably caused by OpenBSD specific stuff (e.g., warnings about the use of unsafe functions like strcpy(3), different output behaviour on signals like SIGSEGV, and, well the unicode (causing unexpected passes) and some threading differences are most probably also OS-dependent candidates). Some problems are not strictly OpenBSD specific, but just triggered due to the more restrictive default limits (number of open file descriptors, datasize, etc.). Finally, some tests just did time out (this isn't the fastest machine in the universe). A full test log is available at http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log And a shorter log (using a really horrible awk script for stripping down the full log): http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.shortlog Fallout from the following tests looks a little bit suspicious: num009 num012 galois_raytrace (well, I didn't read the whol diff ;-)) driver019 (I think a fix for this has been pushed during the last 24 hours) ffi009 tough all the hpc stuff copyFile001 (but there was a push for it recently, IIRC) Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
Hi, On Mon, Sep 22, 2008 at 01:35:43AM +0100, Ian Lynagh wrote: We are pleased to announce that the GHC 6.10.0.20080921 snapshot is a beta release of GHC 6.10.1. [...] Please test as much as possible; bugs are much cheaper if we find them before the release! Not quite the beta snapshot, but from HEAD about the same time you tagged and branched, I got the following positive results on OpenBSD/i386: 1) Build it up to stage2 and make install from ghc-6.6: ok 2) The same again with the result of 1): ok 3) Full build including all extralibs with the result of 2): ok I'll restart the whole process with what's in the ghc-6.10 branch now (hopefully that's ok for you, since some fixes have been already committed to the branch), and I'll also try to run the testsuite after step 3). BTW: I had some problems running the testsuite some weeks ago, because some autoconf'd stuff was missing. When building from the repository (*not* from the source tarballs), are there any additional steps beyond sh boot ./configure --prefix=... gmake install required? Ciao, Kili ps: I've also an amd64 (aka x86_64) at work and will run the tests on it next week. Wether I'll be able to fix the ghci problem in time: no idea. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
Hi, On Tue, Sep 23, 2008 at 03:38:56PM +0200, Christian Maeder wrote: The error far below is caused by -perm /a+x in mk/bindist.mk during find: I've changed it to -perm -111 Unfortunately, this will only find files with the executable bit set for user, group and owner, so it should be -perm +111. However, even more unfortunately, at least the find(1) on OpenBSD doesn't support the +mode pattern. This isn't a problem, because bindist isn't very useful at all on OpenBSD, but it may be a problem on other systems (I don't know what implementation of find(1) are used on FreeBSD, NetBSD and MacOS X). A workaround *may* be to use -perm -100 (setting the execute bit for group and others but not for the user would be really weird). Then make install could not replace links: ln -s runghc /local/home/maeder/bin/runhaskell ln: cannot create /local/home/maeder/bin/runhaskell: File exists gmake[2]: *** [install] Error 2 ln -fs should do the job. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
On Tue, Sep 23, 2008 at 08:34:36PM +0200, Matthias Kilian wrote: I've changed it to -perm -111 Unfortunately, this will only find files with the executable bit set for user, group and owner, so it should be -perm +111. However, even more unfortunately, at least the find(1) on OpenBSD doesn't support the +mode pattern.[...] According to http://www.opengroup.org/onlinepubs/95399/utilities/find.html `-perm +onum' (where onum is an octal number) seems to be yet another gnuism, so `-perm -100' is probably the most portable (and least breaking) option for any system not using gfind. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 beta
On Mon, Sep 22, 2008 at 03:32:40PM +0200, Christian Maeder wrote:
I've tried to build a binary dist on x86 under Solaris and did not succeed.
make binary-dist failed with
1.
for FILE in ; do if [ -e $FILE ]; then echo
ghc-6.10.0.20080921/gmp/$FILE
/export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list
; fi; done
/bin/sh: syntax error at line 1: `;' unexpected
gmake[1]: *** [binary-dist] Error 2
I added strip to bindist.mk:
ifneq $(strip $(BINDIST_EXTRAS))
This part could be done a little bit different (without the
conditional):
...
# And enything else
echo $(BINDIST_EXTRAS) | \
xargs -n1 | \
sed '/^$/d;s/.*/test -e \\ echo $(WHERE_AM_I)\//' | \
sh $(BIND_DIST_LIST)
(untested!)
2.
/bin/sh: test: argument expected
gmake[1]: *** [binary-dist] Error 1
-e does not work for test under sh, so I changed it to -r:
... if [ -r $$FILE ]; then ...
I doubt `-e' doesn't work on Solaris, because `-e' is POSIX. Does
this argument expected still appear with your fix to 1.?
3.
tar hcf /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/ghc-6.10.0.
20080921-i386-unknown-solaris2.tar -T
/export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list
tar: -T: No such file or directory
gmake: *** [binary-dist] Error 1
I changed tar to gtar
Or use pax(1), which in contrast to tar(1) and gtar(1) is POSIX:
pax -hwf $(BIN_DIST_TAR) $(BIN_DIST_LIST)
(also untested, but should work)
4.
gtar: ghc-6.10.0.20080921/gmp/{}: Cannot stat: No such file or directory
The file bindist-list contained {} instead of filenames, so I changed
find to gfind.
Or just omit all the -exec echo ${WHERE_AM_I}/{} goo and use find(1)
and sed(1), e.g.:
find $(WHATEVER) -print | sed 's/^/$(WHERE_AM_I}\//'
5. When trying to install the binary distribution I got:
Installing executable(s) in /local/home/maeder/bin
installPackage: dist-install/build/installPackage/installPackage:
copyFile: does not exist (No such file or directory)
Maybe fallout from some of the above problems?
Ciao,
Kili
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Wed, Aug 13, 2008 at 09:03:34AM +0100, Simon Marlow wrote: Yes, it relies only on the Cabal metadata, but the output is a Makefile only useful for building GHC. Ok, this statement is plainly not true, since I can use 'cabal makefile' to build any package outside of the GHC build tree. So perhaps I've misunderstood your point? No, I was confused (a little bit over-worked). $ ./Setup mkmetadata -prefix foo- which just produces some simple variable declarations like foo-impl-ghc-build-depends = rts foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases [...] Yes, we could use this to implement GHC's build system. It's somewhat similar to the scheme I suggested in the other thread, but more generic. I'd be completely happy to do it this way if the functionality would be useful to others outside GHC too. I've a little bit spare time from august 25th to august 31th. This should be enough time for implementing it (in Cabal and in the GHC build system) to see how it feels. Ciao, Kili -- CRM114 isn't ugly like PERL. It's a whole different kind of ugly. -- John Bowker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Tue, Aug 12, 2008 at 11:59:37AM +0100, Simon Marlow wrote: Well, at least the Makefile creation was a step (the first step?) into the wrong direction, IMHO. I'll run a GHC build to get some of those generated Makefiles and followup on cvs-ghc, but for a starter, Cabal shouldn't know anything about implementation-specific internal build systems; instead it should rely only on it's own metadata. I'm not completely sure, but I think you may have misunderstood how Cabal's makefile generation currently works. It has no specific knowledge of GHC's build system, and it does rely on its own metadata. I mean the GHC-specific template used for building the Makefile (Distribution/Simple/GHC/Makefile.in) and the function `makefile` in Distribution/Simple/GHC.hs (this function even spills out some some make rules in addition to what's in Makefile.in, which looks very wrong to me). Yes, it relies only on the Cabal metadata, but the output is a Makefile only useful for building GHC. It'd be better to be able to run $ ./Setup mkmetadata -prefix foo- which just produces some simple variable declarations like foo-impl-ghc-build-depends = rts foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases ... ... foo-exposed-modules = Control.Applicative Control.Arrow ... ... foo-c-sources = cbits/PrelIOUtils.c cbits/WCsubst.c ... ... foo-windows-extra-libaries = wsock32 msvcrt kernel32 user32 shell32 foo-extensions = CPP foo-ghc-options = -package-name base foo-nhc98-options = -H4M -K3M Basically, the .cabal file is just converted into some other format that may be included by another Makefile. And since it's a really simple output format, it could even be used by different implementations of make(1) or even other build tools. The `foo-' prefix just shields variables in the including Makefile. Take this output, write it to some cabalmetadata.mk, and then use a (GHC-specific) Makefile copied over into all library directories that does an include cabalmetadata.mk ... GHC_OPTS += $(foo-ghc-options) EXPOSED_MODULES = $(foo-exposed-modules) $(foo-impl-ghc-exposed-modules) EXTRA_LIBS = $(foo-extra-libraries) $(foo-$(HostOS_CPP)-extra-libraries) Thus, Cabal dumps the metadata, without knowing how it's used. All the remaining stuff are some (implementation specific) Makefiles relying on recursive variable expansion. I'll implement this for GHC when I've a little bit more spare time (in three or four weeks). (in my other message I'm suggesting moving the Makefile generation into GHC's build system so that it could be made specific to GHC, though). Generated files should be as simple, primitive and portable as possible. Generating complete Makefiles make things more difficult. And it doesn't matter wether they're generated by Cabal or by GHC's build system. If you've to tweak the build system, you don't want to tweak generators but just an existing Makefile. Implementation-specific stuff (such as how to run the compiler) should be supplied by the implementation, not by Cabal. This is what makes me unsure. Implementation of what? The Haskell compiler. Or, to be more exact, the Cabal library shipped with the Haskell compiler (or some supplementary compiler-specific library -- I didn't think much about this part yet). However, my main concern is the usage of Cabal from within the GHC build system, so please just forget this part ;-) Are you suggesting a redesign of Cabal, or just changing the way something works? I don't think that a large redesign is necessary. It should just try to be as implementation-agnostic as possible. Ciao, Kili -- do yourself a favor and let the le(4)s rot on the junkpile of history... -- Henning Brauer ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Tue, Aug 12, 2008 at 10:29:03PM +0200, Matthias Kilian wrote: Basically, the .cabal file is just converted into some other format that may be included by another Makefile. Oops! I again read your (SimonM's) proposal on changing Cabal and the GHC build system in exactly this way. Sorry for the noise. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How MD are .hi files?
On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote: for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. The word size is probably the only dependency, but there are many reasons that you can't just take the .hc/.hi files generated by an unregisterised build on one machine and expect them to work on another machine. I really don't expect this. I just decided to be lazy and provide not only .hc files but also .hi files[1] for the OpenBSD port, and then I thought: does this make sense at all? Can it even be of use for porting GHC to other archs on OpenBSD, or for the NetBSD folks working on GHC? Ciao, Kili [1] Of course, the correct solution would not need the .hi files, but just use the stage1 bootstrapped from .hc files to start rebuilding the libraries. But that would require even more hacking on the Makefiles, and I've already an insane amount of hacks sitting around. -- It compiles -- let's ship it! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How MD are .hi files?
Hi, for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. TIA Ciao, Kili ps: if you think this sounds like a complete newbie question, you're right; I've been far too busy hacking on boring stuff like Makefiles, and didn't have time to look at the interesting code (i.e. ghc itself). My knowledge of ghc's internals is at the state of 1998, or even older, I really don't remember ;-) -- Options are good. As long as they are optional. -- Artur Grabowski ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping for Leopard
On Mon, Feb 04, 2008 at 12:18:01PM +, Simon Marlow wrote: Porting is simply broken for various reasons at the moment - in particular the switch to Cabal for building the libraries broke it. We knew this at the time, but felt it was more important to make the switch now and fix bootstrapping later. Be prepared: I'll send some comments and (probably silly) questions on cvs-ghc@ in a few minutes ;-) For pwd, I imagine the best way forward is to use a C program, I don't think there are any deep issues there. Unless some windows people have the time to step in and help make it work with simple shell stuff, some C helpers would be just fine. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping for Leopard
On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote: [Philip K.F. Hölzenspies:] make hc-file-bundle Making the hc-file-bundle target failed, because not all rts/*.cmm had rts/*.hc counterparts after the build. The make fails because of this fragment from the Makefile (part of the hc-file-bundle target, starting from line 513): for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/rts -name *.cmm -follow -print` ; do \ if test x$$f !=3D x; then \ echo `echo $$f | sed 's/cmm$$/hc/g' ` hc-files-to-go ; \ fi; \ done; This is strange. I've all kinds of trouble getting hc-bootstrapping back (for OpenBSD, but also in general), and I didn't see *that* problem. checking for path to top of build tree... ./configure: line 2651: - v0: command not found ./configure: line 2655: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory [...] This is due to a change of the configure stage that AFAIK was made to easy building on windows. Instead, of using shell commands/scripts (as GHC did previously) to obtain some configuration information (here the file path at which the top of the GHC build tree is located), the build system now uses small Haskell programs/scripts. This makes the build more portable ** if there is already a Haskell compiler on the system **. But it just doesn't make sense at all. You need a good set of shell commands at all, since they're used by configure as well as in Makefiles. I really can't believe that simple stuff like this doesn't work on windos: --- aclocal.m4.orig Mon Dec 10 19:11:31 2007 +++ aclocal.m4 Sun Jan 20 17:10:07 2008 @@ -1098,20 +1098,14 @@ AC_REQUIRE([AC_PROG_CC]) AC_DEFUN([FP_FIND_ROOT],[ AC_MSG_CHECKING(for path to top of build tree) -dnl This would be -dnl make -C utils/pwd clean make -C utils/pwd -dnl except we don't want to have to know what make is called. Sigh. -if test ! -f utils/pwd/pwd test ! -f utils/pwd/pwd.exe; then - cd utils/pwd - rm -f *.o - rm -f *.hi - rm -f pwd - rm -f pwd.exe - $WithGhc -v0 --make pwd -o pwd - cd ../.. -fi - -hardtop=`utils/pwd/pwd forwardslash` +case $HostPlatform in +*cygwin32|*mingw32) + hardtop=`pwd | tr \\ /` + ;; +*) + hardtop=`pwd` + ;; +esac if ! test -d $hardtop; then AC_MSG_ERROR([cannot determine current directory]) ifBuildable.hs is similar; it can be replaced by a shell script or even done within libraries/Makefile using very basic shell commands. The only solution that I see is to replace the Haskell scripts by vanilla shell scripts in HC bundles. Even if that causes problems on windows (without cygwin), it would make HC bundles viable on Unix systems again. How is ghc currently built on windows without something like cygwin? From the source distribution, the only way to build ghc seems to be via configure and (GNU) make. So there must be some shell environment available. Or am I missing something really crucial here? Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on host machine when trying to cross-compile an unregistered build
On Mon, Jan 21, 2008 at 03:23:54PM +, Simon Marlow wrote: First thing to note is that bootstrapping from HC files has bitrotted in 6.8.x, see http://hackage.haskell.org/trac/ghc/ticket/1346. I've updated the wiki instructions to say this. You should go back to 6.6.x, or be prepared to fix things... I thought I remembered someone saying recently they were looking into getting bootstrapping working again, but I can't seem to find it now. That may be me. I've some local patches for obvious offending stuff (like utils/pwd or libraries/ifBuildable), and similar more or less trivia in libraries/Makefile, but I didn't yet even hit the problems I expect for the GNUmakefiles generated by cabal (which I tend to include in a pre-build HC file bundle), not speaking of *real* problems that may (will?) happen on the HC files themselves when all the make issues have been fixed. I asked igloo the other day, and now I ask here: if anyone has *any* attempts for the make problems, even if they don't work, just mail your diffs to me. No promises, no timeline[1], but I really want to get HC bootstrapping back. Ciao, Kili [1] Everytime I expect to have some more time to work on things I want to work on, something bad happens that stops me from doing so. At least within the last 14 months. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: network package
On Fri, Jan 11, 2008 at 09:32:20AM -0800, Don Stewart wrote: I have just built and installed ghc-6.8.2 on my linux box but I can't find the network package. Has it been moved or left out? It's not installed by default. You can find it on hackage.haskell.org, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-2.1.0.0 Yet it's still available in the extralibs tarball. Real slackers just extract extralibs on top of the normal ghc source tarball to get most (not all) of the beloved packages built for free. Just FYI, here are some notes I scribbled down for myself a few days ago when I did some work on the OpenBSD port of GHC (comparing 6.6.1 against 6.8.2 and comparing that against hackage.haskell.org): New (wrt 6.6.1): array, bytestring, containers, directory, hpc, old-locale, old-time, packedstring, parallel, pretty, process, random. Removed from the ghc sources (make separate ports fetching them from hackage): HGL, X11. Note that X11-extras (i.e. port x11/hs-x11-extras) is obsolete now. Available in the extralibs distfile: HUnit, OpenGL, QuickCheck, cgi, fgl, haskell-src, html, mtl, network, parallel, parsec, regex-base, regex-compat, regex-posix, stm, time, xhtml. Version info for packages (no version in Hackage column means same version as for GHC-6.8.2): NameDistGHC-6.8.2 Hackage Cabal base1.2.3.0 HUnit extra 1.2.0.0 OpenGL extra 2.2.1.1 QuickCheck extra 1.1.0.0 array base0.1.0.0 basebase3.0.1.0 n/a bytestring base0.9.0.1 0.9.0.3 cgi extra 3001.1.5.1 containers base0.1.0.1 0.1.0.0 (!) directory base1.0.0.0 fgl extra 5.4.1.1 filepathbase1.1.0.0 ghc base6.8.2 n/a haskell-src extra 1.0.1.1 haskell98 base1.0.1.0 hpc base0.5.0.0 htmlextra 1.0.1.1 mtl extra 1.1.0.0 network extra 2.1.0.0 old-locale base1.0.0.0 old-timebase1.0.0.0 packedstringbase0.1.0.0 parallelextra 1.0.0.0 parsec extra 2.1.0.0 pretty base1.0.0.0 process base1.0.0.0 random base1.0.0.0 readlinebase1.0.1.0 regex-base extra 0.72.0.10.91 regex-compatextra 0.71.0.10.90 regex-posix extra 0.72.0.20.91 rts base1.0 n/a stm extra 2.1.1.0 template-haskellbase(!) 2.2.0.0 timeextra 1.1.2.0 unixbase2.3.0.0 2.2.0.0 (!) xhtml extra 3000.0.2.1 Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on NetBSD Alpha - Dynamic link dependency?
On Fri, Jan 11, 2008 at 11:06:57AM +, Jim Burton wrote: In file included from Stg.h:150, from Rts.h:19, from mkDerivedConstants.c:23: Regs.h:30:45: gmp.h: No such file or directory For a starter, look at http://hackage.haskell.org/trac/ghc/ticket/2009 No idea wether it fixes your problem; you may have to add some more similar changes. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on NetBSD Alpha - Dynamic link dependency?
On Wed, Jan 09, 2008 at 10:41:23PM +, jim burton wrote: Thanks for that, the configure script gets to the end with that help. Following the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#PortingGHCtoanewplatform , I then try to make includes but get a big stream of errors from make. Why is this? The GHC build backs on gmake(1). Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem building on NetBSD Alpha - Dynamic link dependency?
On Wed, Jan 09, 2008 at 07:42:21PM +, jim burton wrote: I'm trying to build unregistered 6.8.2 on NetBSD Alpha 2.1.0_STABLE -- I have the following problem which seems to be same as this one - http://hackage.haskell.org/trac/ghc/ticket/1860 No, I think it's another problem. $ ./configure --enable-hc-boot --enable-hc-boot-unregistered [...] checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure[3201]: -v0: not found ./configure[3203]: utils/pwd/pwd: not found configure: error: cannot determine current directory What happens here is that configure tries to compile some utility program (utils/pwd/pwd) using an existing ghc, which of course is impossible when you're porting ghc a platform not already running ghc. Similar problems are located in libraries and the Cabal-generated GNUmakefiles. For the utils/pwd/pwd problem, I really don't understand why that thing is required at all, since it does little more than get the pwd and add some slash or backslash escaping/quadrupling depending on the argument passed to it. You may try the patch below (and don't forget to re-run autoconf). Note that this is the quick hack I did for OpenBSD. If the forward slash hack of util/pwd is really required (for Windows builds?), something like hardtop=`pwd | tr '\\' /` would be more appropriate. And the other sanity checks I deleted may be necessary in some cases, too, but I really don't see the point in them. Ciao, Kili ps: IMHO, libaries/ifBuildable.hs should die a horrible death, too. It can replaced with a few lines of shell commands.. --- aclocal.m4.orig Mon Dec 10 19:11:31 2007 +++ aclocal.m4 Fri Jan 4 13:58:49 2008 @@ -1098,28 +1098,7 @@ AC_REQUIRE([AC_PROG_CC]) AC_DEFUN([FP_FIND_ROOT],[ AC_MSG_CHECKING(for path to top of build tree) -dnl This would be -dnl make -C utils/pwd clean make -C utils/pwd -dnl except we don't want to have to know what make is called. Sigh. -if test ! -f utils/pwd/pwd test ! -f utils/pwd/pwd.exe; then - cd utils/pwd - rm -f *.o - rm -f *.hi - rm -f pwd - rm -f pwd.exe - $WithGhc -v0 --make pwd -o pwd - cd ../.. -fi - -hardtop=`utils/pwd/pwd forwardslash` - -if ! test -d $hardtop; then - AC_MSG_ERROR([cannot determine current directory]) -fi - -dnl Remove common automounter nonsense -dnl -hardtop=`echo $hardtop | sed 's|^/tmp_mnt.*\(/local/.*\)$|\1|' | sed 's|^/tmp_mnt/|/|'` +hardtop=`pwd` AC_SUBST(hardtop) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 port on FreeBSD-amd64?
On Sun, Jan 06, 2008 at 05:20:18PM +, Ian Lynagh wrote: Prologue junk?: .type s32x_ret, @function s32x_ret: pushl %ebp movl%esp, %ebp I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the gcc-3.3.5 included in its base system. Presumably this also happens if you do a normal build with -fvia-C, i.e. it's not specific to building from an HC file bundle? That's right, it's just -fvia-C that triggers the bug. [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, it should be -fviaC -keep-hc-files. Someone let me know if I should correct this in the wiki. GHC will act as if -fvia-C is given if -keep-hc-files is given. It would be nice to update the wiki to say -fvia-C rather than -fasm to avoid confusion, though. Done. ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's a must-have for the OpenBSD port. Note that there is a plan to drop the registerised via-C way of compiling GHC at some point, so this isn't going to work in the long term (unless you want to bootstrap via an unregisterised compiler). I think I'll be happy with unregisterised bootstrap, too, even if the actual build of the port will take longer. Would it not be possible to have a ghc-bin package in OpenBSD, which contains a precompiled binary that can be used to compile a ghc source package? I think Gentoo does something like that. AFAIK, FreeBSD does it in a similar way. However, this isn't the way we do ports for OpenBSD, so I'll work towards the unregisterised bootstrap. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 port on FreeBSD-amd64?
[Note: already shortly discussed with Wilhelm] On Fri, Nov 23, 2007 at 12:30:06PM +, Wilhelm B. Kloke wrote: ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include HsUnix.h -#include execvpe.h -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H32m -O0 -fasm -Rghc-timing -keep-hc-files -O -c dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o -ohi dist/build/System/Posix/Process.hi Prologue junk?: .type s32x_ret, @function s32x_ret: pushl %ebp movl%esp, %ebp I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the gcc-3.3.5 included in its base system. Regardless of wether there's something wrong with the generated code or wether it's just a bug in the mangler, it's possible to build Process.c with -fviaC *and* -O0.[1] For now, I'm able to build a HC file bundle with this settings in build.mk and running gmake stage1 hc-file-bundle: SRC_HC_OPTS=-H64 -O -fvia-C -keep-hc-files GhcLibHcOpts= -O0 # Workaround the mangler problem GhcLibWays= GhcRTSWays= SplitObjs= NO I'd appreciate any reports wether people see the same problem on other systems (if so: what gcc version are you using?) and wether GhcLibHcOpts=-O0 fixes it. Ciao, Kili [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, it should be -fviaC -keep-hc-files. Someone let me know if I should correct this in the wiki. ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's a must-have for the OpenBSD port. Apart from the HC file bundle, this will require some more hacking especially on library/Makefile and the Cabal-generated GNUmakefiles (and/or Makefile.local). pps: I guess, cvs-ghc would be the more correct list for sending patches and discussing the bootstrapping stuff, right? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
On Tue, May 29, 2007 at 04:15:29PM +0100, Simon Marlow wrote: What puzzles me a little bit is the fact that this does *not* happen on amd64 (aka x86_64) but only on i386 so far. So does this ring a bell for anyone? I didn't find anything similar in the archives or in the bug tracker. No ringing bells here I'm afraid. What you're seeing is a failure from the code that checks for memory leaks, which is only enabled by -debug (the threaded1 test way uses -threaded -debug). It reckons you have 508 blocks allocated from the OS, but can only account for 255 of them. You could try enabling some more debugging options, e.g. +RTS -DSb will enable sanity-checking and debugging messages from the block allocator. This, and with some more debugging output and gdb sessions, helped. The problem is that in hs_init(), initAdjustor() is called *before* initStorage(). initAdjustor() is a NOOP everywhere except for OpenBSD/i386, where it calls allocateExec(). Later in hs_init(), when initStorage() is invoked, the free_list is reset, but mblocks_allocated is still 1 = bummer. Now my GHC knowledge is still very rusty (I didn't look at it for years), so I really don't know wether that initAdjustor() is still needed nor what it's good for, or if its invocation can be moved after initStorage(). Any hint appreciated. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
Hi, I'm currently working on updating the GHC port to 6.6.1 for OpenBSD, and when I run the testsuite (ghc-regress), all test cases for the way threaded1, i.e. debug + threaded bail out with an assertion failure: Blocks: 132 live + 123 free = 255 total (508 around) conc010: internal error: ASSERTION FAILED: file Storage.c, line 1174 The numbers vary slightly, but there's always a total of 255 and 508 blocks around, except for one test case (con012), where there are a total of 763 blocks (1016 around). What puzzles me a little bit is the fact that this does *not* happen on amd64 (aka x86_64) but only on i386 so far. So does this ring a bell for anyone? I didn't find anything similar in the archives or in the bug tracker. Ciao, Kili -- CRM114 isn't ugly like PERL. It's a whole different kind of ugly. -- John Bowker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testsuite for GHC version 6.6.1?
On Fri, May 04, 2007 at 02:48:13PM +0200, Christian Maeder wrote: How or where can I pick up the testsuite for this new version? I want to test my own builds. http://www.haskell.org/ghc/dist/6.6.1/ghc-testsuite-6.6.1.tar.gz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
perl frontend for ghc
Hi! I hope this isn't a FAQ, but AFAIR this hasn't been asked in the past: Are there plans to replace the ghc frontend (driver), which is currently written in perl, by a version implemented in Haskell? I know that perl is nice for fiddling with command line options, but on the other hand, it's a very chaotic programming language. So, are there any reasons beyond speed and/or the simple fact that nobody did port the frontend to Haskell? Bye, Kili -- signature intentionally left blank
Re: ANNOUNCE: GHC 4.06 released
Hi! I wonder what the cvs release naming strategy is. Ist 4.06 on the main cvs branch, or is there a special tag for official releases, or what else? A `cvs up -dPA -r 4.06' in the fptools directory simply removed everything (don't worry, I did make a copy before the update). Bye, Kili
RE: Patches for GHC 4.04pl1?
The best thing to do is use the anoncvs repository, and just 'cvs update' to get the latest patches. If you're running over a phone line then it might help to make ssh do some compression. Yes, but this requires at least one complete checkout. Of course, after this is done, cvs update will only load the diffs to newer versions. And: isn't there a risk to update the local sources to a `unstable' revision? Or do you use symbolic tags for official releases, such as `ghc4.04pl1'? I'll use cvs to get the latest ghc, but nevertheless I suggest to publish patch files for future releases of ghc. This shouldn't be too difficult: cvs co -r lastRel -d ghc.old ghc cvs co -D now ghc cd ghc diff -rNu ../ghc.old . ../ghc.diffs cvs tag -F lastRel cd .. cvs -q rel -d ghc.old cvs -q rel -d ghc Bye, Kili -- de: Signaturen erzeugen Krebs. en: Signatures cause cancer. Please send other translations.
RE: Searching for the gcc-2.95 problem
Perhaps the same is happening with GHC's RTS. You can ask gcc-2.95 to be less aggressive by using -fno-strict-aliasing (I think; consult the documentation). I'd be interested to hear if this makes any difference. I've already tried this with no success. However, it seems that during the make process not every files are compiled with `$(TOP)/ghc/drivers/ghc'. Some are compiled with the standard ghc which (in my setup) uses plain gcc withou -fno-strict-aliasing. So I have to try it again, with my installed ghc driver patched. BTW: Are there any gcc-related problems apart from that I reported (you remember, the funny thing with the hamming numbers)? I think there was mail reporting core dumps, but I can't find it in my mail folders. Kili
Success story (was: Re: Where are ghc-4.02 .hc files?)
Thank you all for your tips. I've compiled first ghc-3.02 using the .hc files and then ghc-4.02 which required an additional -dcore-lint on the following files: compiler/rename/ParseIface.lhs lib/exts/Int.lhs lib/exts/Word.lhs lib/posix/PosixTTY.lhs + lib/std/PrelArr.lhs lib/std/PrelHandle.lhs lib/std/Random.lhs In addition to this, I also had to switch optimization off (-Onot) for lib/posix/PosixTTY.lhs. Now I can say that ghc-4.02 seems to work on Linux 2.2.5 with glibc-2.1.1pre1 and egcs-1.1.2. I did a three-stage bootstrapping without any further problems. Regards, Kili
