Done: http://ghc.haskell.org/trac/ghc/ticket/8376
I'll try to extend it with more information as I try to figure out exactly what is causing the segfault -- Christiaan On Sep 28, 2013, at 9:17 AM, Carter Tazio Schonwald <[email protected]> wrote: > please report this issue on ghc trac and all the relevant information there > in. That is the best way to promptly get folks to see it > > -Carter > > > On Saturday, September 28, 2013 at 2:55 AM, Christiaan Baaij wrote: > >> Yes, I have both the static libs and the dynamic libs. >> So for every library I have both the 'libHS<PACKAGE-VERSION>.a' and the >> 'libHS<PACKAGE-VERSION-ghc<GHCVERSION>.dylib' files. >> And for all the compiled modules I have both the '.hi' and '.dyn_hi' files. >> >> So to be clear: >> - I have both the static and dynamic versions of all libraries/packages >> >> - I built a statically-linked executable by setting 'executable-dynamic' in >> my '.cabal/config' file explicitly to 'False' >> - otool -L <EXE> confirms that the executable is indeed statically linked >> - Running the statically-linked executable that uses the GHC API, where the >> GHC API does dynamic linking (e.g. TH) => Segfault >> >> - I built a dynamically-linked executable setting 'executable-dynamic' in my >> '.cabal/config' file explicitly to 'True' >> - otool -L <EXE> confirms that the executable is indeed dynamically linked. >> - Running the dynamically-linked binary that uses the GHC API, where the GHC >> API does dynamic linking => No problem, behaves normally >> >> So the problem is not that TH is not working/segfaulting, the problem is >> that I get segfaults when a statically linked executable does dynamic >> linking. >> At least on OS X. >> >> -- Christiaan >> >> >> >> On Sat, Sep 28, 2013 at 4:23 AM, Carter Schonwald >> <[email protected]> wrote: >>> Hey Christian, did you build ghc and libs I both Dylib and static ways? TH >>> uses ghci, and ghci on OS X and a few other platforms uses the system >>> dylinker, so it may be that you've only built certain libs the static way, >>> but ghci requires the dynamic way as of 7.7 >>> >>> Please let me know if that helps. >>> >>> >>> >>> >>> On Friday, September 27, 2013, Christiaan Baaij wrote: >>>> Dear all, >>>> >>>> It seems that executables that use the GHC API require to be dynamically >>>> linked on GHC 7.7. >>>> At least in the case that an GHC API function has to perform linking. >>>> Statically linked executable SEGFAULT when a GHC API function tries to do >>>> linking. >>>> >>>> I build 'haddock' from source by doing a 'cabal install' in the >>>> 'utils/haddock' directory of my ghc build tree. >>>> Here is the output of my statically linked haddock when I run it on one of >>>> my libraries: >>>> Haddock coverage: >>>> Warning: main:CLaSH.Util: Could not find documentation for exported >>>> module: X >>>> Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses >>>> 95% ( 18 / 19) in 'CLaSH.Util' >>>> 100% ( 8 / 8) in 'CLaSH.Core.TyCon' >>>> 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' >>>> 100% ( 5 / 5) in 'CLaSH.Core.DataCon' >>>> 100% ( 3 / 3) in 'CLaSH.Core.Literal' >>>> 100% ( 5 / 5) in 'CLaSH.Core.Var' >>>> Bus error: 10 <-- SEGFAULT >>>> >>>> Here is the output of my dynamically linked haddock when I run it on one >>>> of my libraries: >>>> Haddock coverage: >>>> Warning: main:CLaSH.Util: Could not find documentation for exported >>>> module: X >>>> Warning: Couldn't find .haddock for export Control.Lens.TH.makeLenses >>>> 95% ( 18 / 19) in 'CLaSH.Util' >>>> 100% ( 8 / 8) in 'CLaSH.Core.TyCon' >>>> 100% ( 6 / 6) in 'CLaSH.Core.TysPrim' >>>> 100% ( 5 / 5) in 'CLaSH.Core.DataCon' >>>> 100% ( 3 / 3) in 'CLaSH.Core.Literal' >>>> 100% ( 5 / 5) in 'CLaSH.Core.Var' >>>> 100% ( 5 / 5) in 'CLaSH.Core.Term' >>>> 100% ( 8 / 8) in 'CLaSH.Core.Subst' >>>> 100% ( 24 / 24) in 'CLaSH.Core.Type' >>>> <… lots of warnings about missing link destination … > >>>> ~/Documents/devel/clash/src (master *)$ >>>> >>>> I believe that the use of TH in the CLaSH.Core.Var file triggers the >>>> segfault in the statically linked version. >>>> I'm trying to create a smaller test case than running haddock on my >>>> library, but have been unsuccessful so far. >>>> That is why I haven't posted a bug report on the bug tracker yet. >>>> If somebody thinks I should, then please say so :-) >>>> >>>> My platform is: >>>> OS: OS X 10.8.5 >>>> XCode: X-Code CL-tools 4.6.2 >>>> GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546) >>>> Build.mk: >>>> SRC_HC_OPTS = -O -H64m >>>> GhcStage1HcOpts = -O -fasm >>>> GhcStage2HcOpts = -O2 -fasm >>>> GhcHcOpts = -Rghc-timing >>>> GhcLibHcOpts = -O2 >>>> HADDOCK_DOCS = NO >>>> >>>> I hope somebody can test this on linux with dynamic linking. >>>> As this bug affects haddock, I think it is quite important that somebody >>>> with more knowledge of dynamic linking looks into this. >>>> >>>> Regards, >>>> >>>> Christiaan >>>> >>>> >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> [email protected] >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
