occasional linking problems with --make?
I'm just wondering if other GHC users see the errors I see. Occasionally, a program will fail to link, with an error similar to the following: Linking build/test/RunTests ... lUndefined symbols: "_UiziRulerC_dk8C", referenced from: _skev_info in RulerC.o ld: symbol(s) not found collect2: ld returned 1 exit status The program involves some C FFI, the Ui.RulerC module mention above is one such FFI-using module. It's consistent in that if I do another 'make' I'll keep seeing the error, but inconsistent in that if I rm a bunch of .o files to force them to recompile, I usually get a successful link afterwards. I haven't really figured out what exact files I need to rebuild, but I don't think it's necessarily just the "referenced from" module, on occasion deleting a bunch of files doesn't solve the problem and I just do a 'make clean'. I haven't noticed if it's always FFI using modules, or which exact .o files I have to delete to fix the problem, but I'll pay more attention in the future. I've been seeing this problem pretty regularly (maybe once every couple of weeks) since upgrading to ghc7 a long time ago. Do other people see this same issue? Is there something I can do to better track it down, other than the two things I mentioned above? I'd like to blame my hacky makefile, but then again all the haskell modules use --make so it seems like ghc is to blame. Also, when I remove an import from a module I can fairly reliably get the "modules below me: missing <module no longer imported>, hi files probably out of date" warning from every module above. It's annoying but seems to be harmless, and when I get tired of the noise I do a make clean. Is this a common problem? I feel like there's something wrong in the dependency tracking that yields these problems. This is ghc 7.0.2, btw.
Just as an addendum, this just happened again, but I got new errors this time. Make gave the usual: Linking build/test/RunTests ... Undefined symbols: "_UiziTrackC_d28LF", referenced from: _s28UI_info in TrackC.o "_UiziRulerC_dk8C", referenced from: _skev_info in RulerC.o ld: symbol(s) not found collect2: ld returned 1 exit status But then reloading that same module in ghci gave a new one:
:r [ 23 of 124] Compiling Ui.UiMsg ( Ui/UiMsg.hs, interpreted )
Ui/UiMsg.hs:51:31: Can't find interface-file declaration for type constructor or class Key.Modifier Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the type `[Key.Modifier]' In the definition of data constructor `Mouse' In the data type declaration for `Data' The odd thing is that after restarting ghci and loading there was no problem, so I didn't get a chance to try its -ddump-if-trace suggestion. In this case before the reload I had added an instance declaration to a type in the Key module, though oddly it wasn't the referenced Modifier type. Removing the referenced .o files and recompiling was enough to fix the link error.
On 02/08/2011 06:52, Evan Laforge wrote:
Just as an addendum, this just happened again, but I got new errors this time. Make gave the usual:
Linking build/test/RunTests ... Undefined symbols: "_UiziTrackC_d28LF", referenced from: _s28UI_info in TrackC.o "_UiziRulerC_dk8C", referenced from: _skev_info in RulerC.o ld: symbol(s) not found collect2: ld returned 1 exit status
But then reloading that same module in ghci gave a new one:
:r [ 23 of 124] Compiling Ui.UiMsg ( Ui/UiMsg.hs, interpreted )
Ui/UiMsg.hs:51:31: Can't find interface-file declaration for type constructor or class Key.Modifier Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the type `[Key.Modifier]' In the definition of data constructor `Mouse' In the data type declaration for `Data'
The odd thing is that after restarting ghci and loading there was no problem, so I didn't get a chance to try its -ddump-if-trace suggestion. In this case before the reload I had added an instance declaration to a type in the Key module, though oddly it wasn't the referenced Modifier type.
Removing the referenced .o files and recompiling was enough to fix the link error.
Can you save the state at some point when the error happen? Preferably when using --make rather than GHCi. Just tar/zip the whole directory and send it to us, with instructions to reproduce the error. What platform is this BTW? Cheers, Simon
Can you save the state at some point when the error happen? Preferably when using --make rather than GHCi. Just tar/zip the whole directory and send it to us, with instructions to reproduce the error. What platform is this BTW?
Sure, I'll do that next time it comes up. It'll be a couple hundred MB so I'll just send a download link. This is OS X 10.6.7.
participants (2)
-
Evan Laforge -
Simon Marlow