GHC status report

Carter Schonwald carter.schonwald at gmail.com
Mon May 5 21:08:29 UTC 2014


i don't have 7.6 setup anymore, i'll see about reproducing the issue later.
it falls under the umbrella of "linking not working in ghci", But it could
be that didn't try the -fshared-llvm + ghci in 7.6


On Mon, May 5, 2014 at 5:01 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 05/05/14 21:58, Carter Schonwald wrote:
>
>> no, i was saying LLVM-General when static linked to llvm doesnt work. I
>> wasnt talking about ghc being dynamic or static
>>
>
> I believe you that it doesn't work.  But I think that if you use a
> dynamically-linked llvm (i.e. the shared-llvm flag), it *should* work, even
> with 7.6.3.  What goes wrong in that case?
>
> Cheers,
> Simon
>
>  merely that theres no way to get llvm-general to work on ghci in 7.6 afaik
>>
>>
>> On Mon, May 5, 2014 at 4:54 PM, Simon Marlow <marlowsd at gmail.com
>> <mailto:marlowsd at gmail.com>> wrote:
>>
>>     I don't see any reason why llvm-general with the shared-llvm flag
>>     shouldn't work with a statically linked GHCi (7.6.3 or 7.8 with
>>     DYNAMIC_GHC_PROGRAMS=NO).  Doesn't it work?
>>
>>
>>     On 03/05/14 02:12, Carter Schonwald wrote:
>>
>>         if theres a way i can patch llvm-general so that i can use it
>>         with llvm
>>         static linked into rather than dylinked, i'm all ears!
>>
>>         llvm-general has to use some C++ wrappers (that in turn use
>>         extern "C"
>>         sections) to make parts of the llvm api accessible from hasskell.
>>
>>         I had trouble following some of the thread earlier today, but is
>> the
>>         suggestion to try building those wrappers with -fPIC would make
>> them
>>         play nice?
>>
>>
>>         On Fri, May 2, 2014 at 8:52 PM, Dominick Samperi
>>         <djsamperi at gmail.com <mailto:djsamperi at gmail.com>
>>         <mailto:djsamperi at gmail.com <mailto:djsamperi at gmail.com>>> wrote:
>>
>>              I posted a ticket related to this (#8371), but the example
>>         provided
>>              there
>>              has no problems today for all versions of ghci that I
>>         tested (including
>>              7.6.3), provided -fno-ghci-sandbox is specified. So this
>>         problem was
>>              clearly related to the threads issue.
>>
>>              Today there are problems when DYNAMIC_GHC_PROGRAMS=NO, but
>> they
>>              happen later, and I have not yet narrowed this down to a
>>         small example.
>>              Basically, I have an Haskell app that embeds R (as in the
>>         sample code
>>              attached to the above ticket), but when it tries to do some
>>         calculations
>>              it seg faults (works fine with 7.8.2).
>>
>>              On Fri, May 2, 2014 at 3:45 PM, Simon Marlow
>>         <marlowsd at gmail.com <mailto:marlowsd at gmail.com>
>>              <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>>
>> wrote:
>>               > Can you give me a quick summary of how to reproduce the
>>         problem? (not
>>               > including the GHC build steps)
>>               >
>>               > Cheers,
>>               > Simon
>>               >
>>               >
>>               > On 02/05/14 18:18, Dominick Samperi wrote:
>>               >>
>>               >> I downloaded HEAD and placed DYNAMIC_GHC_PROGRAMS=NO in
>>         the "quick"
>>               >> section of mk/build.mk <http://build.mk>
>>         <http://build.mk> (with BuildFlavour =
>>
>>              quick), and set
>>               >> DYNAMIC_GHC_PROGRAMS=NO
>>               >> in my environment before running configure (just to be
>>         sure!). Near
>>               >> the end of the build
>>               >> I saw some messages like "Warning: vectorization
>>         failure," but the
>>               >> build completed.
>>               >>
>>               >> The status at the end of configure doesn't say that
>>         dynamic linking
>>               >> via RTS has been
>>               >> turned off, and I don't know how to check that this is
>> so.
>>               >> Nevertheless, I checked
>>               >> the linking issue and it is NOT fixed with this build, so
>>               >> DYNAMIC_GHC_PROGRAMS=YES is required to prevent the
>>         problems
>>               >> reported by me and others.
>>               >>
>>               >>
>>               >> On Fri, May 2, 2014 at 9:09 AM, Simon Marlow
>>         <marlowsd at gmail.com <mailto:marlowsd at gmail.com>
>>              <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>>
>> wrote:
>>               >>>
>>               >>> On 02/05/2014 01:09, Dominick Samperi wrote:
>>               >>>
>>               >>>> If I understand your last comment correctly linking
>>         to libR should
>>               >>>> continue to work, even if you revert to static
>>         linking of Haskell
>>               >>>> compiled
>>               >>>> code via RTS linker. Since you say this is the way
>>         things have
>>              always
>>               >>>> been, perhaps the real explanation for why 7.8 fixed
>>         the issue
>>              is that
>>               >>>> some bug was fixed along the way...
>>               >>>
>>               >>>
>>               >>>
>>               >>> Indeed.  To know for sure we would have to test 7.8 with
>>               >>> DYNAMIC_GHC_PROGRAMS=NO with your setup - is there a
>>         way to do
>>              that?
>>               >>>
>>               >>> Cheers,
>>               >>> Simon
>>               >>>
>>               >>>
>>               >>>
>>               >>>> Note that R is a C library, so the C++ issues that
>> Carter
>>              mentions are
>>               >>>> not a factor here.
>>               >>>>
>>               >>>> Thanks,
>>               >>>> Dominick
>>               >>>>
>>               >>>> On Thu, May 1, 2014 at 5:27 PM, Simon Marlow
>>              <marlowsd at gmail.com <mailto:marlowsd at gmail.com>
>>         <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>> wrote:
>>               >>>>>
>>               >>>>>
>>               >>>>> On 01/05/14 14:48, Dominick Samperi wrote:
>>               >>>>>>
>>               >>>>>>
>>               >>>>>>
>>               >>>>>> The problem with some graphics libraries used via
>>         FFI (and other
>>               >>>>>> libraries
>>               >>>>>> that are not thread-safe), if I understand the
>>         situation
>>              correctly, is
>>               >>>>>> that ghci
>>               >>>>>> forks a thread when it shouldn't, causing some
>>         programs to
>>               >>>>>> miscalculate
>>               >>>>>> the available stack space (because they think there
>>         is only one
>>               >>>>>> thread).
>>               >>>>>
>>               >>>>>
>>               >>>>>
>>               >>>>>>
>>               >>>>>>
>>               >>>>>> The new dynamic linking support and the flag
>>              -fno-ghci-sandbox fixes
>>               >>>>>> this problem, and I would not vote for the removal
>>         of these
>>              features.
>>               >>>>>
>>               >>>>>
>>               >>>>>
>>               >>>>>
>>               >>>>> So I understand how -fno-ghci-sandbox avoids
>>         problems with GUI
>>               >>>>> libraries
>>               >>>>> that use thread-local state.  But how is dynamic
>> linking
>>              involved here?
>>               >>>>> What improved in GHC 7.8 relative to 7.6 for you?
>>         And could
>>              you clarify
>>               >>>>> "miscalculate the available stack space"? What needs
>> to
>>              calculate stack
>>               >>>>> space? Why? C stack space?
>>               >>>>>
>>               >>>>> We can certainly make a smoother experience around
>>              -fno-ghci-sandbox
>>               >>>>> for
>>               >>>>> using GUI libraries.
>>               >>>>>
>>               >>>>>
>>               >>>>>> It is not clear to me from Simon's original post
>>         how linking
>>              to all of
>>               >>>>>> those C++ libs can continue to work if dynamic
>>         linking is
>>              removed
>>               >>>>>> in 7.10? Perhaps I misunderstand what you mean by
>>         "revert to
>>               >>>>>> static linking"?
>>               >>>>>
>>               >>>>>
>>               >>>>>
>>               >>>>>
>>               >>>>> When I say "revert to static linking" I mean make
>>         GHCi static
>>              linked,
>>               >>>>> and
>>               >>>>> have it load Haskell code compiled for static
>>         linking using
>>              the RTS
>>               >>>>> linker
>>               >>>>> (like it did in 7.6).  Foreign libraries would still
>> be
>>              loaded using
>>               >>>>> the
>>               >>>>> system linker, as they always have been.
>>               >>>>>
>>               >>>>> To be clear, I'm not officially proposing that we drop
>>              dynamic linking,
>>               >>>>> but
>>               >>>>> I think it's worthwhile exploring the design space
>>         again,
>>              given that we
>>               >>>>> know
>>               >>>>> dynamic linking has been tougher than we expected.
>>               >>>>>
>>               >>>>> Cheers,
>>               >>>>> Simon
>>               >>>>>
>>               >>>>>
>>               >>>>>
>>               >>>>>> Thanks,
>>               >>>>>> Dominick
>>               >>>>>>
>>               >>>>>>
>>               >>>>>> On Wed, Apr 30, 2014 at 9:26 PM, George Colpitts
>>               >>>>>> <george.colpitts at gmail.com
>>         <mailto:george.colpitts at gmail.com>
>>              <mailto:george.colpitts at gmail.__com
>>
>>         <mailto:george.colpitts at gmail.com>>> wrote:
>>               >>>>>>>
>>               >>>>>>>
>>               >>>>>>>
>>               >>>>>>> To elaborate, in the past, I had a lot of problems
>>         using
>>              libraries
>>               >>>>>>> from
>>               >>>>>>> the
>>               >>>>>>> ghci prompt on the Mac but I haven't tried recently.
>>               >>>>>>>
>>               >>>>>>> As an example, on the web page for the book the
>>         Haskell
>>              School of
>>               >>>>>>> Expression
>>               >>>>>>> it says:
>>               >>>>>>>
>>               >>>>>>> Note for OS X users: running graphics applications
>>         from
>>              GHCi is no
>>               >>>>>>> longer
>>               >>>>>>> supported. Instead, one has to compile a graphics
>>         program
>>              using GHC
>>               >>>>>>> in
>>               >>>>>>> order
>>               >>>>>>> to run it (see example/GMIExamples.lhs for an
>>         example).
>>               >>>>>>>
>>               >>>>>>> I had similar problems using the Yale Euterpea music
>>              program from
>>               >>>>>>> ghci.
>>               >>>>>>> When
>>               >>>>>>> I inquired I was referred to
>>               >>>>>>> https://ghc.haskell.org/trac/__ghc/ticket/4244
>>         <https://ghc.haskell.org/trac/ghc/ticket/4244>
>>               >>>>>>> and https://ghc.haskell.org/trac/__ghc/ticket/781
>>         <https://ghc.haskell.org/trac/ghc/ticket/781>. I see that the
>>
>>               >>>>>>> latter
>>               >>>>>>> is
>>               >>>>>>> now scheduled for 7.10.1
>>               >>>>>>>
>>               >>>>>>>
>>               >>>>>>> On Wed, Apr 30, 2014 at 1:45 PM, Simon Marlow
>>              <marlowsd at gmail.com <mailto:marlowsd at gmail.com>
>>         <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>>
>>
>>
>>               >>>>>>> wrote:
>>               >>>>>>>>
>>               >>>>>>>>
>>               >>>>>>>>
>>               >>>>>>>>
>>               >>>>>>>> On 30/04/2014 01:35, George Colpitts wrote:
>>               >>>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>> It doesn't have anything about the dynamic linking
>>              changes made for
>>               >>>>>>>>> 7.8.
>>               >>>>>>>>> I think it's worth mentioning the improvements
>>         we expect
>>              to get
>>               >>>>>>>>> from
>>               >>>>>>>>> that. The highlights of the release notes do
>>         mention it,
>>              so maybe
>>               >>>>>>>>> that
>>               >>>>>>>>> suffices.
>>               >>>>>>>>>
>>               >>>>>>>>> In particular, I'm hoping that it is going to
>>         fix a lot
>>              of problems
>>               >>>>>>>>> with
>>               >>>>>>>>> using foreign libraries such as OpenGL from
>>         ghci. I could
>>              be wrong
>>               >>>>>>>>> about
>>               >>>>>>>>> that though.
>>               >>>>>>>>
>>               >>>>>>>>
>>               >>>>>>>>
>>               >>>>>>>>
>>               >>>>>>>>
>>               >>>>>>>> I'd like to understand more about what those
>>         problems are.
>>                As a
>>               >>>>>>>> data
>>               >>>>>>>> point, at Facebook we're using static linking (I
>>         compiled
>>              GHC with
>>               >>>>>>>> DYNAMIC_GHC_PROGRAMS=NO), we're loading upwards of
>> 50
>>              3rd-party C++
>>               >>>>>>>> libraries and one gigantic shared library
>>         consisting of a
>>              ton of
>>               >>>>>>>> in-house
>>               >>>>>>>> C++ code, together with all our Haskell code into
>>         GHCi,
>>              and it works
>>               >>>>>>>> perfectly.  The key to using the static linker is
>>         to not
>>              use it for
>>               >>>>>>>> C++
>>               >>>>>>>> code
>>               >>>>>>>> - you want all your external C++ code in shared
>>         libraries
>>              and load
>>               >>>>>>>> those
>>               >>>>>>>> using the system linker.
>>               >>>>>>>>
>>               >>>>>>>> Dynamic linking has been a huge headache in GHC,
>>         and it's
>>              not clear
>>               >>>>>>>> that
>>               >>>>>>>> it's an overall improvement compared with the
>> static
>>              linker.  Now
>>               >>>>>>>> that
>>               >>>>>>>> 7.8
>>               >>>>>>>> is out of the way, it's time to have a
>>         conversation about
>>              whether we
>>               >>>>>>>> want to
>>               >>>>>>>> do dynamic linking again for 7.10, or revert to
>>         static
>>              linking.  I
>>               >>>>>>>> think
>>               >>>>>>>> Austin is going to update
>>               >>>>>>>>
>>         https://ghc.haskell.org/trac/__ghc/wiki/DynamicGhcPrograms
>>         <https://ghc.haskell.org/trac/ghc/wiki/DynamicGhcPrograms>,
>>
>>              and then
>>               >>>>>>>> we'll
>>               >>>>>>>> see
>>               >>>>>>>> where we stand.
>>               >>>>>>>>
>>               >>>>>>>> Cheers,
>>               >>>>>>>> Simon
>>               >>>>>>>>
>>               >>>>>>>>
>>               >>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>> On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton
>> Jones
>>               >>>>>>>>> <simonpj at microsoft.com
>>         <mailto:simonpj at microsoft.com> <mailto:simonpj at microsoft.com
>>         <mailto:simonpj at microsoft.com>>
>>              <mailto:simonpj at microsoft.com
>>         <mailto:simonpj at microsoft.com> <mailto:simonpj at microsoft.com
>>         <mailto:simonpj at microsoft.com>>__>> wrote:
>>               >>>>>>>>>
>>               >>>>>>>>>        As Austin has told us, there's a draft of
>>         the *GHC
>>              Status
>>               >>>>>>>>> Report
>>               >>>>>>>>> for
>>               >>>>>>>>>        the HCAR*, here:____
>>               >>>>>>>>>
>>               >>>>>>>>>
>>         https://ghc.haskell.org/trac/__ghc/wiki/Status/May14____
>>
>>         <https://ghc.haskell.org/trac/ghc/wiki/Status/May14____>
>>               >>>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>>        Have we missed out something  you have been
>>              working hard on?
>>               >>>>>>>>> Do
>>               >>>>>>>>>        take a moment to add a bullet in an
>>         appropriate
>>              place (it's
>>               >>>>>>>>> a
>>               >>>>>>>>>        wiki).  I'd like to be sure that we are
>>         giving
>>              credit to all
>>               >>>>>>>>> the
>>               >>>>>>>>>        appropriate people, so please help us fix
>>         that
>>              too.  GHC is
>>               >>>>>>>>> a
>>               >>>>>>>>> team
>>               >>>>>>>>>        effort.____
>>               >>>>>>>>>
>>               >>>>>>>>>        Deadline is 1 May I think.____
>>               >>>>>>>>>
>>               >>>>>>>>>        Thanks____
>>               >>>>>>>>>
>>               >>>>>>>>>        Simon____
>>               >>>>>>>>>
>>               >>>>>>>>>        __ __
>>               >>>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>>
>>           _________________________________________________
>>
>>               >>>>>>>>>        ghc-devs mailing list
>>               >>>>>>>>> ghc-devs at haskell.org
>>         <mailto:ghc-devs at haskell.org> <mailto:ghc-devs at haskell.org
>>         <mailto:ghc-devs at haskell.org>>
>>              <mailto:ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>         <mailto:ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>>
>>
>>
>>               >>>>>>>>>
>>         http://www.haskell.org/__mailman/listinfo/ghc-devs
>>         <http://www.haskell.org/mailman/listinfo/ghc-devs>
>>               >>>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>>
>>               >>>>>>>>> _________________________________________________
>>               >>>>>>>>> ghc-devs mailing list
>>               >>>>>>>>> ghc-devs at haskell.org
>>         <mailto:ghc-devs at haskell.org> <mailto:ghc-devs at haskell.org
>>         <mailto:ghc-devs at haskell.org>>
>>               >>>>>>>>>
>>         http://www.haskell.org/__mailman/listinfo/ghc-devs
>>         <http://www.haskell.org/mailman/listinfo/ghc-devs>
>>               >>>>>>>>>
>>               >>>>>>>
>>               >>>>>>>
>>               >>>>>>> _________________________________________________
>>
>>               >>>>>>> ghc-devs mailing list
>>               >>>>>>> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>         <mailto:ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>
>>               >>>>>>> http://www.haskell.org/__mailman/listinfo/ghc-devs
>>         <http://www.haskell.org/mailman/listinfo/ghc-devs>
>>               >>>>>>>
>>               >>>>>
>>               >>>
>>               >
>>              _________________________________________________
>>
>>              ghc-devs mailing list
>>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>         <mailto:ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>
>>         http://www.haskell.org/__mailman/listinfo/ghc-devs
>>         <http://www.haskell.org/mailman/listinfo/ghc-devs>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140505/65985919/attachment-0001.html>


More information about the ghc-devs mailing list