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] > (mailto:[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
