Executables using GHC API require dynamic linking in GHC 7.7

[Christiaan Baaij]

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 <carter.schonwald at gmail.com> 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 <carter.schonwald at gmail.com> 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
>>>> Glasgow-haskell-users at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> 
>