One of GHC's infelicities is that it only supports tuples up to a certain size -- currently 62. You just can't get bigger tuples. Your program uses a 73-tuple. My guess is that your code is generated by some other program that's generating big tuples? The only workaround is to nest your tuples. It would really be much better if GHC complained in the front end about over-size tuples. I'll fix that. The "real" fix (arbitrary size tuples) isn't really hard, but it involves real work so we keep postponing it on the gounds that it seldom bites. So please continue to say if it bites you, so that we know. It used to be the case that simply having a nest of more than 62 mutually-recursive functions would trigger this bug, but that should no longer be the case with 6.0. Please say if that is happening. Simon | -----Original Message----- | From: glasgow-haskell-users-admin@haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of A.P. Rao | Sent: 04 August 2003 05:50 | To: glasgow-haskell-users@haskell.org | Subject: linker errors | | Hi, | | I am getting an "undefined reference" error listed | below when I try to | build my program. I am able to successfully compile | and link a trivial | "Hello World" program, but not my application code. | | I tried 3 different versions of ghc (5.04.3, 6.0 and | 6.0.1) on my | redhat-9 linux pc. The gcc compiler is at version | 3.2.2 (gcc (GCC) | 3.2.2 20030222 (Red Hat Linux 3.2.2-5)). I even | tried the ghc 6.0.1 | compiler built on my own pc. The result is the same. | | Error: | -------------------- | AsnParser.o(.text+0x21139): In function `r2CD0_entry': | : undefined reference to `DataziTuple_Z73T_con_info' | collect2: ld returned 1 exit status | -------------------- | | Any suggestions as to what may be causing this and | how I can get rid | of it. To me, it looks like a code-generation bug on | ghc's side. | | Thanks, | A.P. Rao | | | __________________________________ | Do you Yahoo!? | Yahoo! SiteBuilder - Free, easy-to-use web site design software | http://sitebuilder.yahoo.com | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
The code is hand-written and the maximum tuple-size
used is 4. It works fine in Hugs. It uses the Parsec
library (not the version in GHC's "text" package, but
from a local copy. The ParsecPrim.hs was replaced by
the version from Parsec's web-site -- it works as I
expected, but not the one distributed with GHC or
Hugs).
The code makes straight-forward use of Parsec
combinators for parsing ASN.1, and I can't see a
nesting of anything close to 62 mutually recursive
functions.
If there is a "readme" type of document that explains
the names and the tables generated in the ".hc" files,
it may help me track down what construct is causing
this problem. Right now, I can't recognize anything
in the lines surrounding the place where this
DataziTuple_Z73T_con_info symbol is used in the ".hc"
file.
Thanks,
A.P. Rao.
--- Simon Peyton-Jones
One of GHC's infelicities is that it only supports tuples up to a certain size -- currently 62. You just can't get bigger tuples. Your program uses a 73-tuple. My guess is that your code is generated by some other program that's generating big tuples?
The only workaround is to nest your tuples.
It would really be much better if GHC complained in the front end about over-size tuples. I'll fix that. The "real" fix (arbitrary size tuples) isn't really hard, but it involves real work so we keep postponing it on the gounds that it seldom bites. So please continue to say if it bites you, so that we know.
It used to be the case that simply having a nest of more than 62 mutually-recursive functions would trigger this bug, but that should no longer be the case with 6.0. Please say if that is happening.
Simon
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
participants (2)
-
A.P. Rao -
Simon Peyton-Jones