20

I'm having issues doing a cabal run on my project. This project used to run properly, and I'm not totally sure what change broke it. I think it is related to the issues between GHC 7.6 and OSX Mavericks (I'm using Darin Morrison's homebrew formulae here). [Edit: to clarify, this was working at one point on Mavericks, so this hypothesis may not hold up.] The problem appears to be in the linking step:

In-place registering chorez-0.1.0.0...
Preprocessing executable 'chorez' for chorez-0.1.0.0...
Linking dist/build/chorez/chorez ...
Undefined symbols for architecture x86_64:
  "_chorezzzm0zi1zi0zi0_ChorezzziRequest_AddResponse_con_info", referenced from:
      _s5X4_info in libHSchorez-0.1.0.0.a(Commands.o)
  "_chorezzzm0zi1zi0zi0_ChorezzziRequest_ErrorResponse_static_info", referenced from:
      _chorezzzm0zi1zi0zi0_ChorezzziCommands_route1_closure in libHSchorez-0.1.0.0.a(Commands.o)
  "_chorezzzm0zi1zi0zi0_ChorezzziRequest_parseRequest_closure", referenced from:
      _r7eV_srt in libHSchorez-0.1.0.0.a(Server.o)
  "_chorezzzm0zi1zi0zi0_ChorezzziRequest_parseRequest_info", referenced from:
      _s7nh_info in libHSchorez-0.1.0.0.a(Server.o)
  "_chorezzzm0zi1zi0zi0_ChorezzziRequest_zdfToJSONResponse1_closure", referenced from:
      _r7eS_closure in libHSchorez-0.1.0.0.a(Server.o)
  "_chorezzzm0zi1zi0zi0_ChorezzziRequest_zdfToJSONResponse4_closure", referenced from:
      _s7ng_info in libHSchorez-0.1.0.0.a(Server.o)
      _r7eQ_closure in libHSchorez-0.1.0.0.a(Server.o)
      _r7eV_srt in libHSchorez-0.1.0.0.a(Server.o)
  "_chorezzzm0zi1zi0zi0_ChorezzziRequest_zdfToJSONResponse5_closure", referenced from:
      _s7ng_info in libHSchorez-0.1.0.0.a(Server.o)
      _r7eV_srt in libHSchorez-0.1.0.0.a(Server.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

All of these symbols are from my own project (judging by the names). Most answers that I've seen about this have to do with a certain library not linking properly. I suspect some of these symbols are generated by deriveToJSON from Data.Aeson.TH. I've reinstalled a couple of times with no resolution. Any ideas?

benekastah
  • 5,651
  • 1
  • 35
  • 50

3 Answers3

31

Here's what finally fixed it. My cabal config was something like this:

library
  exposed-modules:
      My.Module1
    , My.Module3


executable my-executable
  main-is:             Main.hs
  build-depends:
      base >=4.6 && <4.7
    , chorez

Main.hs for the executable imports My.Module3. My.Module3 imports the private My.Module2. Including My.Module2 under exposed-modules fixed the issue. I figured this out because I realized that all the symbols that couldn't be found came from that module. cabal repl worked just fine (I tested the modules by hand and they all basically worked), but cabal run didn't. I feel like I should be able to use a library with private modules in an executable, but in this case I just forgot to add the new module to the list, and I have no reason to make any module private, so I'm up and running for now.

benekastah
  • 5,651
  • 1
  • 35
  • 50
  • This works for me. I had a private extras module, And a test that imported only the public module. – sam boosalis Oct 06 '14 at 04:55
  • 3
    This also worked for me, but I agree that there seems to be a deeper problem here. It doesn't make sense that you have to expose all modules that are used internally... – Will Sewell Mar 29 '15 at 16:36
  • Thank you! I had the same error and I had accidentally forgot to include one of the modules in my build-depends. Adding it in my `exposed-modules` solved it. – Ecognium Jul 29 '15 at 18:12
9

A bit late to the party, but what you want is to put your non-exposed modules in the other-modules section.

From the Cabal User Guide:

Modules included in the package

For a library, cabal init looks in the project directory for files that look like Haskell modules and adds all the modules to the exposed-modules field. For modules that do not form part of your package’s public interface, you can move those modules to the other-modules field. Either way, all modules in the library need to be listed.

mattjbray
  • 565
  • 3
  • 8
2

Uninstall and reinstall - not GHC, but Xcode. That resolved the issue for me.

Mark Reed
  • 91,912
  • 16
  • 138
  • 175
  • Nope. I uninstalled XCode and tried again. Didn't work. I then tried to reinstall ghc and cabal-install again (just in case the freshly installed build tools would do a better job). I finally checked again just now, and that didn't work either. – benekastah Nov 02 '13 at 23:35