RE: Linker errors when using FFI on Windows
That did it, thanks. Instead of using ghc's -L/-l flags, I used: -optl c:\windows\system32\ntwdblib.dll > -Original Message- > From: Sigbjorn Finne [mailto:[EMAIL PROTECTED] > Sent: 28 April 2005 01:04 > To: Bayley, Alistair > Cc: glasgow-haskell-users@haskell.org > Subject: Re: Linker errors when using FFI on Windows > > Adding the -Lc:\windows\system32 option when linking upsets > the resolution of misc standard libraries, causing 'ld' to > use the DLLs > rather than the mingw link libraries, including msvcrt.dll. > > Try just using c:/windows/system32/ntwdblib.dll on the link > line instead. > If ld's DLL auto-import support doesn't quite work, attempting to link > with the import library 'ntwdblib' (ntwdblib.lib ?) instead > is worth a shot. > The SQL Server SDK ought to include that somewhere. > > hth > --sigbjorn > > - Original Message - > From: "Bayley, Alistair" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, April 27, 2005 08:10 > Subject: Linker errors when using FFI on Windows > > > > I'm trying to link an FFI program against a Windows (XP) DLL > > (c:\windows\system32\ntwdblib - this is the MS Sql Server > client library). > > The output from ghc6.4 -v is below; the errors start in the Linker > > section. > > > > Comments: > > > > - Where do these objects dxx.o come from? (They're not in my > > source...) > > > > d13.o(.text+0x0): multiple definition of `_onexit' > > c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x2a0):crt1.c: first > defined here > > d18.o(.text+0x0): multiple definition of `atexit' > > c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x280):crt1.c: first > defined here > > > > > > - Have I omitted some important linker flag? There are tons of these > > undefined references from crt2.o, like this: > > > > c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x238):crt1.c: > undefined reference to > > [EMAIL PROTECTED]' > > > > > > Thanks, > > Alistair. > > > > - * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linker errors when using FFI on Windows
Adding the -Lc:\windows\system32 option when linking upsets the resolution of misc standard libraries, causing 'ld' to use the DLLs rather than the mingw link libraries, including msvcrt.dll. Try just using c:/windows/system32/ntwdblib.dll on the link line instead. If ld's DLL auto-import support doesn't quite work, attempting to link with the import library 'ntwdblib' (ntwdblib.lib ?) instead is worth a shot. The SQL Server SDK ought to include that somewhere. hth --sigbjorn - Original Message - From: "Bayley, Alistair" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 27, 2005 08:10 Subject: Linker errors when using FFI on Windows I'm trying to link an FFI program against a Windows (XP) DLL (c:\windows\system32\ntwdblib - this is the MS Sql Server client library). The output from ghc6.4 -v is below; the errors start in the Linker section. Comments: - Where do these objects dxx.o come from? (They're not in my source...) d13.o(.text+0x0): multiple definition of `_onexit' c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x2a0):crt1.c: first defined here d18.o(.text+0x0): multiple definition of `atexit' c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x280):crt1.c: first defined here - Have I omitted some important linker flag? There are tons of these undefined references from crt2.o, like this: c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x238):crt1.c: undefined reference to [EMAIL PROTECTED]' Thanks, Alistair. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linker errors
> The compiler has generated intermediate code which uses a 77-tuple, but > unfortunately the libraries don't contain code for 77-tuples (we only go > up to 62-tuples). > > This is kind of a known bug, occasionally tickled by Happy-generated > parsers. > > If you're not generating your parser with 'happy -agc', then that should > help. > > Cheers, > Simon Thank you a lot. As simple as it is, it really helped. Thanks to Volker and Johannes, too. Greetings, Frank-Andre ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linker errors
On 13 September 2004 17:44, Frank-Andre Riess wrote: > this is my first post on this list. I'm quite new to using Haskell > (started in July), so my question might be somewhat trivial, but I > still hope you can help me out. > > At the moment our project - a parser for a type language - consists > of the following modules: > Lexer > IntermediateSyntax > Parser (from a Happy source file) - uses Lexer and IntermediateSyntax > Main - uses Parser > > When compiling using ghc, I get the following error: > > Parser.o(.text+0x10fc5): In function `r1fgN_entry': >> undefined reference to `DataziTuple_Z77T_con_info' > collect2: ld returned 1 exit status > > I neither know the function `r1fgN_entry' nor > `DataziTuple_Z77T_con_info'. So what is it? The compiler has generated intermediate code which uses a 77-tuple, but unfortunately the libraries don't contain code for 77-tuples (we only go up to 62-tuples). This is kind of a known bug, occasionally tickled by Happy-generated parsers. If you're not generating your parser with 'happy -agc', then that should help. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: linker errors
In gmane.comp.lang.haskell.glasgow.user, you wrote: > When compiling using ghc, I get the following error: > Parser.o(.text+0x10fc5): In function `r1fgN_entry': >: undefined reference to `DataziTuple_Z77T_con_info' > collect2: ld returned 1 exit status What platform and gcc? Could you please invoke ghc with -v and paste the output? Is this a ghc built from CVS or a binary version? Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME Two more month. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linker errors
Hi, > Passing "-O" flag to ghc has solved the problem for > now. But since a lot more code is yet to be written, > I will keep my fingers crossed if the "-O" flag will > continue to avoid the "undefined symbol" problem at > the link-stage. > > Looking at the intermediate code generated by ghc with > "-ddump-ds" option, it seems that ghc is generating > code that groups functions involved in certain > call-chains (whether contributing to recursion or > not), difines them in a "__letrec" block, and puts > them in a tuple, and generates outer definititons of > these functions by using differfent elements in the > tuple. This bug has been fixed, sorry for not noticing before. The fix wasn't merged into 6.0.1, but it will be in 6.2. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linker errors
Passing "-O" flag to ghc has solved the problem for now. But since a lot more code is yet to be written, I will keep my fingers crossed if the "-O" flag will continue to avoid the "undefined symbol" problem at the link-stage. Looking at the intermediate code generated by ghc with "-ddump-ds" option, it seems that ghc is generating code that groups functions involved in certain call-chains (whether contributing to recursion or not), difines them in a "__letrec" block, and puts them in a tuple, and generates outer definititons of these functions by using differfent elements in the tuple. While I don't understand why this is done, it is very unreasonable to fix a limit of 62 for such tuple-sizes, because this limit can easily be exceeded by good, hand-written code, for example, when implementing parsers for complicated language definitions (not because the user-code uses big tuples, but because of the tuples generated by ghc itself). Manually analysing and restructuring the code in such cases to work around this compiler limitation is not realistic. Is this limitation purely a result of using Base-62 numbers in compiler/basicTypes/Unique.lhs ? If so, will changing this one file and redefining the mAX_TUPLE_SIZE fix the problem? The best solution perhaps is to avoid generation of such tuples altogether. I also see the following note in ghc.spec file. Is that related to the current issue ? If so, is this limitation non-existent in that particular version of GHC? --- * Thu Sep 16 1999 Manuel Chakravarty - modified for GHC 4.04, patchlevel 1 (no more 62 tuple stuff); --- I wish I could volunteer to fix this problem, but I don't understand what is really going on. Will somebody who knows the internals of GHC fix this? Or, is this such a low-priority task that it will never get scheduled ? Unfortunately, neither of the other two Haskell compilers are alternative solutions due to other limitations. Thanks, A.P. Rao. --- "A.P. Rao" <[EMAIL PROTECTED]> wrote: > > 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 <[EMAIL PROTECTED]> > wrote: > > 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 > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linker errors
| 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). Well that is mysterious. Can you send the offending source code (plus the modules it imports, and a Makefile)? Preferably with as few imports as possible... Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linker errors
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 <[EMAIL PROTECTED]> wrote: > 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: linker errors
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of A.P. Rao | Sent: 04 August 2003 05:50 | To: [EMAIL PROTECTED] | 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 | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
