Executables using GHC API require dynamic linking in GHC 7.7

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Executables using GHC API require dynamic linking in GHC 7.7

Carter Schonwald
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 (mailto: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
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130928/9fb18a7e/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

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
>>
>