I downloaded HEAD and placed DYNAMIC_GHC_PROGRAMS=NO in the "quick" section of mk/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 <marlo...@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 <marlo...@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.colpi...@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 >>>>> and 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 <marlo...@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, and then >>>>>> we'll >>>>>> see >>>>>> where we stand. >>>>>> >>>>>> Cheers, >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones >>>>>>> <simo...@microsoft.com <mailto:simo...@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____ >>>>>>> >>>>>>> >>>>>>> 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@haskell.org <mailto:ghc-devs@haskell.org> >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs@haskell.org >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs@haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>> > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
