On Mon, May 5, 2014 at 4:54 PM, Simon Marlow <marlowsd@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@gmail.com
<mailto:djsamperi@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@gmail.com
<mailto:marlowsd@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> (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@gmail.com
<mailto:marlowsd@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@gmail.com <mailto:marlowsd@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@gmail.com
<mailto:george.colpitts@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
<marlowsd@gmail.com <mailto:marlowsd@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
>>>>>>>>> <simonpj@microsoft.com <mailto:simonpj@microsoft.com>

<mailto:simonpj@microsoft.com <mailto:simonpj@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>

<mailto: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 <mailto:ghc-devs@haskell.org>
>>>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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 <mailto:ghc-devs@haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs