How to solve ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) issue.
Hello, recently I've found out that my solaris-based GHC buildbot is completely unusable since it always (when it get to, which means it does not fail with usual magic number mismatch: old/corrupt interface file?) fails with: "inplace/bin/ghc-stage2" -H32m -O -DNEW_GHC_LAYOUT -hide-all-packages -i -iutils/haddock/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.7.4 -package array-0.2.0.1 -package base-4.2.0.0 -package containers-0.2.0.1 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package ghc-6.11.20090915 -package pretty-1.0.1.0 -funbox-strict-fields -O2 -Wall -XForeignFunctionInterface -XCPP -XPatternGuards -XDeriveDataTypeable -XScopedTypeVariables -XMagicHash -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/haddock/src/Haddock/GhcUtils.hs -o utils/haddock/dist/build/Haddock/GhcUtils.o ghc-stage2: mkTextEncoding: invalid argument (Invalid argument) make[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.o] Error 1 make: *** [all] Error 2 I've even tried to update my building GHC from 6.8.3 to 6.10.4, but it still does not help. Since I would really like to resurrect my GHC buildbot, do you have any idea how to fix this issue? Thanks, Karel PS: for reference, please have a look at http://darcs.haskell.org/buildbot/all/builders/kgardas%20head
On Tue, 2009-09-15 at 16:56 +0200, Karel Gardas wrote:
Hello,
recently I've found out that my solaris-based GHC buildbot is completely unusable since it always (when it get to, which means it does not fail with usual magic number mismatch: old/corrupt interface file?) fails with:
ghc-stage2: mkTextEncoding: invalid argument (Invalid argument)
So that's when it calls iconv_open with the names of some text encodings. Apparently that is failing. You should be able to confirm this with some tracing.
I've even tried to update my building GHC from 6.8.3 to 6.10.4, but it still does not help.
No, it wouldn't.
Since I would really like to resurrect my GHC buildbot, do you have any idea how to fix this issue?
Dig into base/GHC/IO/Encoding/Iconv.hs mkTextEncoding function where it calls iconv_open, see what it's being called with. In particular check if HAVE_LANGINFO_H is getting defined. If it's not then the code assumes GNU iconv.
PS: for reference, please have a look at http://darcs.haskell.org/buildbot/all/builders/kgardas%20head
See also the http://darcs.haskell.org/buildbot/head/builders/sparky%20head Which is running Solaris 10 on sparc and seems to be working fine. Duncan
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 see: http://darcs.haskell.org/buildbot/all/builders/kgardas%20head/builds/205/ste... When I've seen the code it's not so surprising that it fails in this way, what's in fact surprising to me is that sparky passes belong this point: checking for library containing iconv... none required configure: creating ./config.status config.status: creating base.buildinfo config.status: creating include/HsBaseConfig.h [...] See: http://darcs.haskell.org/buildbot/head/builders/sparky%20head/builds/91/step... I'm sorry for starting this #91 build on sparky, but I'd like verify that it does not build older source-code than my buildbot. So now, the question is: is GNU iconv really required or if it's not, how to make my buildbot ignoring it as sparky's buldbot seems to be doing? Thanks, Karel Duncan Coutts wrote:
Dig into base/GHC/IO/Encoding/Iconv.hs mkTextEncoding function where it calls iconv_open, see what it's being called with.
In particular check if HAVE_LANGINFO_H is getting defined. If it's not then the code assumes GNU iconv.
PS: for reference, please have a look at http://darcs.haskell.org/buildbot/all/builders/kgardas%20head
See also the
http://darcs.haskell.org/buildbot/head/builders/sparky%20head
Which is running Solaris 10 on sparc and seems to be working fine.
Duncan
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
I've experienced a similar problem under i386 solaris, see http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017376.html The problem seems to be the file /usr/local/include/iconv.h without a corresponding library. HTH Christian 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
see: http://darcs.haskell.org/buildbot/all/builders/kgardas%20head/builds/205/ste...
When I've seen the code it's not so surprising that it fails in this way, what's in fact surprising to me is that sparky passes belong this point:
checking for library containing iconv... none required configure: creating ./config.status config.status: creating base.buildinfo config.status: creating include/HsBaseConfig.h [...]
See: http://darcs.haskell.org/buildbot/head/builders/sparky%20head/builds/91/step...
I'm sorry for starting this #91 build on sparky, but I'd like verify that it does not build older source-code than my buildbot.
So now, the question is: is GNU iconv really required or if it's not, how to make my buildbot ignoring it as sparky's buldbot seems to be doing?
Thanks, Karel
Duncan Coutts wrote:
Dig into base/GHC/IO/Encoding/Iconv.hs mkTextEncoding function where it calls iconv_open, see what it's being called with.
In particular check if HAVE_LANGINFO_H is getting defined. If it's not then the code assumes GNU iconv.
PS: for reference, please have a look at http://darcs.haskell.org/buildbot/all/builders/kgardas%20head See also the
http://darcs.haskell.org/buildbot/head/builders/sparky%20head
Which is running Solaris 10 on sparc and seems to be working fine.
Duncan
Thanks to Christian note I solved the issue. Also thanks to Matthias' advice I've been able to configure ghc to use GNU iconv in /usr/local, but the result was still the same. I later used Christian advice to force ghc not to use /usr/local's iconv and this really configured correctly (like sparky's: checking for library containing iconv... none required) and now finally my buildbot is working even for head. Note the provided /usr/local iconv is probably from package provided by sunfreeware.com and is there from the old SXDE 1/08 installation. Now I'm using OpenSolaris 2009.06 and trying to get rid of such additions which are no longer needed. Thanks for all the help provided! Karel Christian Maeder wrote:
I've experienced a similar problem under i386 solaris, see http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017376.html
The problem seems to be the file /usr/local/include/iconv.h without a corresponding library.
HTH Christian
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
see: http://darcs.haskell.org/buildbot/all/builders/kgardas%20head/builds/205/ste...
When I've seen the code it's not so surprising that it fails in this way, what's in fact surprising to me is that sparky passes belong this point:
checking for library containing iconv... none required configure: creating ./config.status config.status: creating base.buildinfo config.status: creating include/HsBaseConfig.h [...]
See: http://darcs.haskell.org/buildbot/head/builders/sparky%20head/builds/91/step...
I'm sorry for starting this #91 build on sparky, but I'd like verify that it does not build older source-code than my buildbot.
So now, the question is: is GNU iconv really required or if it's not, how to make my buildbot ignoring it as sparky's buldbot seems to be doing?
Thanks, Karel
Duncan Coutts wrote:
Dig into base/GHC/IO/Encoding/Iconv.hs mkTextEncoding function where it calls iconv_open, see what it's being called with.
In particular check if HAVE_LANGINFO_H is getting defined. If it's not then the code assumes GNU iconv.
PS: for reference, please have a look at http://darcs.haskell.org/buildbot/all/builders/kgardas%20head See also the
http://darcs.haskell.org/buildbot/head/builders/sparky%20head
Which is running Solaris 10 on sparc and seems to be working fine.
Duncan
On 16/09/2009 15:06, Karel Gardas wrote:
Thanks to Christian note I solved the issue. Also thanks to Matthias' advice I've been able to configure ghc to use GNU iconv in /usr/local, but the result was still the same. I later used Christian advice to force ghc not to use /usr/local's iconv and this really configured correctly (like sparky's: checking for library containing iconv... none required) and now finally my buildbot is working even for head.
Note the provided /usr/local iconv is probably from package provided by sunfreeware.com and is there from the old SXDE 1/08 installation. Now I'm using OpenSolaris 2009.06 and trying to get rid of such additions which are no longer needed.
Thanks for all the help provided!
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.normalised Wed Sep 16 14:08:09 2009 +++ ./lib/IO/hClose002.run.stdout.normalised Wed 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). Cheers, Simon
Hi, indeed, I know that and I expect to submit patches later this month. Thanks, Karel 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.normalised Wed Sep 16 14:08:09 2009 +++ ./lib/IO/hClose002.run.stdout.normalised Wed 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).
Cheers, Simon
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.normalised Wed Sep 16 14:08:09 2009 +++ ./lib/IO/hClose002.run.stdout.normalised Wed 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
On 17/09/2009 22:20, Matthias Kilian wrote:
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.normalised Wed Sep 16 14:08:09 2009 +++ ./lib/IO/hClose002.run.stdout.normalised Wed 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.
This is slightly ad-hoc at the moment and could do with generalising a bit. Look at the various functions beginning with normalise_ in testsuite/driver/testlib.py. There's also a way to specify a per-test output normalisation function: normalise_fun(). Cheers, Simon
participants (5)
-
Christian Maeder -
Duncan Coutts -
Karel Gardas -
Matthias Kilian -
Simon Marlow