Would the SxS loader (with associated manifests, etc) work? I've used
it to support similar scenarios in a former job without any PE32
hacking. Unless things have changed recently, the APIs aren't super
well documented but they are supported and there are a handful of
tools for tracing the loader t
On 06/12/12 21:35, Brandon Allbery wrote:
On Thu, Dec 6, 2012 at 4:04 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
On 05/12/12 15:17, Brandon Allbery wrote:
Probably none; on most platforms you're actually generating
different
code (dynamic libraries require g
On Thu, Dec 6, 2012 at 4:04 PM, Simon Marlow wrote:
> On 05/12/12 15:17, Brandon Allbery wrote:
>
>> Probably none; on most platforms you're actually generating different
>> code (dynamic libraries require generation of position-independent
>>
> Sure there's a lot of differences in the generated
On 05/12/12 15:17, Brandon Allbery wrote:
On Wed, Dec 5, 2012 at 12:03 AM, Chris Smith mailto:cdsm...@gmail.com>> wrote:
I'm curious how much of the "compile twice" situation for static and
dynamic libraries could actually be shared.
Probably none; on most platforms you're actually gen
On 6 December 2012 10:05, Max Bolingbroke wrote:
> I've tested this by hand and it seems like it works: the absolute
> paths you hack into the import library are not messed with by the
> later link step. The resulting executables run flawlessly. Job done.
To continue spamming the list, I'd just l
On 6 December 2012 09:27, Max Bolingbroke wrote:
> I'm not sure how to convince GNU ld to link us such a DLL, though. It
> might be possible to hack it in by linking against
> "verylongdummydllname.dll" and then having GHC search for that string
> in DLL/EXE returned by LD and replace it by the nu
On 27 November 2012 17:00, Ian Lynagh wrote:
> We would love for Windows to be one of the platforms, but currently we
> can't do it on Windows. So unless that changes, Windows will not be one
> of the platforms, correct.
So if I understand correctly, the problem here arises because you
can't impo
On Wed, Dec 5, 2012 at 12:03 AM, Chris Smith wrote:
> I'm curious how much of the "compile twice" situation for static and
> dynamic libraries could actually be shared.
Probably none; on most platforms you're actually generating different code
(dynamic libraries require generation of position-i
I'm curious how much of the "compile twice" situation for static and
dynamic libraries could actually be shared. Even if it's not likely to be
implemented in the next year or two, IMO it would make a big difference if
it were feasible to generate both static and dynamic libraries at the same
time
Agreed. I'd much rather never again problems in ghci + linking,
Its one of the biggest sources of exotic bugs for new haskellers on OS X,
for all that i've never quite managed to ever pin down a simple test case
to replicate those problems
point being: ghci should do normal dynamic linking for re
Simon Marlow :
>> This has some advantages and some disadvantages, so we need to make a
>> decision about what we want to do in GHC 7.8. There are also some policy
>> questions we need to answer about how Cabal will work with a GHC that
>> uses dynamic libraries by default. We would like to make th
On Tue, 27 Nov 2012 20:15:59 + Ian Lynagh
wrote:
> It will be easy to turn it off, but depending on the platform we might
> have removed support for GHCi when it's turned off.
Why not provide RTS linker as a deprecated option at least until it's
completely removed from all platforms? I mostl
Hi,
Am Freitag, den 30.11.2012, 12:28 + schrieb Simon Marlow:
>
> Static by default, GHCi is dynamic:
> * fast code and compiler
> * GHCi bugs are fixed, no maintenance problems
> * binaries not broken by library updates
> * we have to build packages twice in Cabal (but can improve GH
On Wed, Nov 28, 2012 at 1:45 AM, Joachim Breitner wrote:
> At the moment, I do not see how dynamically built
> Haskell programs are in the interest of our user.
>
They do offer the prospect of fixing some annoying bugs for free, by
offloading them to existing, working system infrastructure. For i
Hi,
a bit late but here are my comments:
- my main (and in a way ``only'') concern is speed. At some point I'd
like my programs to consistently beat the pants off C ...
This won't happen soon, but when comparing to C it makes a difference
being able to say Haskell is x1.3 slower or x1.4 slo
On Fri, Nov 30, 2012 at 12:28:41PM +, Simon Marlow wrote:
>
> Static by default, GHCi is dynamic:
> * still can't do this on Windows
We can do it on Windows: We can use side-by-side assemblies.
(well, assuming we fix #5987).
Thanks
Ian
___
Gla
Simon Marlow writes:
[...]
> Perhaps we should look again at the option that we discarded: making
> -static the default, and require a special option to build objects for
> use in GHCi. If we also build packages both static+dynamic at the
> same time in Cabal, this might be a good compromise.
>
On 27/11/12 14:52, Ian Lynagh wrote:
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
This has some advantages and some disadvantages, so we need to make a
decision about what we
On 28/11/12 23:15, Johan Tibell wrote:
What does gcc do? Does it link statically or dynamically by default?
Does it depend on if it can find a dynamic version of libraries or
not?
If it finds a dynamic library first, it links against that.
Unlike GHC, with gcc you do not have to choose at comp
What does gcc do? Does it link statically or dynamically by default?
Does it depend on if it can find a dynamic version of libraries or
not?
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman
Ian Lynagh writes:
> On Wed, Nov 28, 2012 at 12:34:03PM +0100, Herbert Valerio Riedel wrote:
>> Ian Lynagh writes:
>>
>> [...]
>>
>> > There are also some policy questions we need to answer about how Cabal
>> > will work with a GHC that uses dynamic libraries by default.
>>
>> btw, how is it
Hi,
Am Mittwoch, den 28.11.2012, 11:35 -0500 schrieb Tyson Whitehead:
> > > I was left with the impression that we were going to have this back in
> > > 2010 just as soon as squeeze got out the door... :)
> >
> > It seems that noone cared enough about that, but any help is welcome.
> > Two thing
On Wed, Nov 28, 2012 at 11:04:44AM -0500, Stephen Paul Weber wrote:
>
> >Building them also in the dynamic way for the sake of GHCi users seems
> >possible.
>
> Perhaps Debian could just ship a GHCi that uses the RTS linker, as
> now? The change is to be made for "some platforms", we could opt t
On November 27, 2012 22:02:33 Jens Petersen wrote:
> > GHC HEAD now has support for using dynamic libraries by default (and in
> > particular, using dynamic libraries and the system linker in GHCi) for a
> > number of platforms.
>
> I am very happy to hear this news.
>
> I have long been a quiet
On November 28, 2012 04:45:57 Joachim Breitner wrote:
> Am Dienstag, den 27.11.2012, 21:57 -0500 schrieb Tyson Whitehead:
> > I was so excited for a bit thinking that this would finally mean that
> > Debian would move to a dynamic system. Every haskell binary being 10s
> > of MBs (e.g., pandoc = 2
On Wed, Nov 28, 2012 at 01:34:22PM +, Ganesh Sittampalam wrote:
> On 28/11/2012 13:13, Ian Lynagh wrote:
>
> >> More generally, if you can implement the "half a plan" you mentioned
> >> elsewhere in the thread for quickly building both static and dynamic
> >> ways, then the combination of the
Somebody signing messages as Joachim Breitner wrote:
Given the current sensitivity of the ABI hashes we really do not want to
have Programs written in Haskell have a runtime dependency on all the
included Haskell libraries. So I believe we should still link Haskell
programs statically in Debian.
On Wed, Nov 28, 2012 at 01:28:54PM +, Simon Marlow wrote:
> On 28/11/12 12:48, Ian Lynagh wrote:
> >On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote:
> >>
> >>My personal opinion is that we should switch to dynamic-by-default
> >>on all x86_64 platforms, and OS X x86.
I should have
On 28/11/2012 13:13, Ian Lynagh wrote:
>> My general feeling about Windows is that it's ok for the end result to
>> be a little annoying, because Windows DLLs *are* annoying and it's
>> nothing to do with GHC.
>>
>> In particular I think in practice most Windows developers will have
>> admin right
On 28/11/12 12:48, Ian Lynagh wrote:
On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote:
My personal opinion is that we should switch to dynamic-by-default
on all x86_64 platforms, and OS X x86. The performance penalty for
x86/Linux is too high (30%),
FWIW, if they're able to move f
On Wed, Nov 28, 2012 at 06:43:09AM +, Ganesh Sittampalam wrote:
> On 27/11/2012 14:52, Ian Lynagh wrote:
>
> > GHC HEAD now has support for using dynamic libraries by default (and in
> > particular, using dynamic libraries and the system linker in GHCi) for a
> > number of platforms.
> >
> >
On Wed, Nov 28, 2012 at 04:00:02PM +0900, Jens Petersen wrote:
>
> Could you say more about the impact to ghc-7.6.2 Cabal?
For example, question 8 is about whether Cabal should also build static
libraries for a dynamic-by-default compiler. We would like to ship a
version of Cabal that does the ri
On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote:
>
> My personal opinion is that we should switch to dynamic-by-default
> on all x86_64 platforms, and OS X x86. The performance penalty for
> x86/Linux is too high (30%),
FWIW, if they're able to move from x86 static to x86_64 dynamic
On Wed, Nov 28, 2012 at 09:09:58AM +, Simon Marlow wrote:
> On 27/11/12 23:28, Joachim Breitner wrote:
> >
> >Hence, Debian will continue to provide its libraries built the static
> >way.
>
> So let me try to articulate the options, because I think there are
> some dependencies that aren't obv
On Wed, Nov 28, 2012 at 12:28:31AM +0100, Joachim Breitner wrote:
>
> here comes the obligatory butting in by the Debian Haskell Group:
>
> Given the current sensitivity of the ABI hashes we really do not want to
> have Programs written in Haskell have a runtime dependency on all the
> included H
On Wed, Nov 28, 2012 at 12:34:03PM +0100, Herbert Valerio Riedel wrote:
> Ian Lynagh writes:
>
> [...]
>
> > There are also some policy questions we need to answer about how Cabal
> > will work with a GHC that uses dynamic libraries by default.
>
> btw, how is it planned to have .so libraries i
Ian Lynagh writes:
[...]
> There are also some policy questions we need to answer about how Cabal
> will work with a GHC that uses dynamic libraries by default.
btw, how is it planned to have .so libraries interact with the
soon-to-be-released cabal-install sandbox feature?
___
Hi,
Am Dienstag, den 27.11.2012, 21:57 -0500 schrieb Tyson Whitehead:
> I was so excited for a bit thinking that this would finally mean that
> Debian would move to a dynamic system. Every haskell binary being 10s
> of MBs (e.g., pandoc = 25MB executable) makes it look kind of bad.
its not like
Am Mittwoch, den 28.11.2012, 16:14 +0900 schrieb Jens Petersen:
> On 28 November 2012 08:28, Joachim Breitner wrote:
> > Open question: What should GHC on Debian do when building binaries,
> > given that all libraries are likely available in both ways – shared or
> > static. Shared means that all
On 27/11/12 14:52, Ian Lynagh wrote:
Hi all,
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
This has some advantages and some disadvantages, so we need to make a
decision abou
On 27/11/12 23:28, Joachim Breitner wrote:
Hi,
Am Dienstag, den 27.11.2012, 14:52 + schrieb Ian Lynagh:
The various issues are described in a wiki page here:
http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
If you have a few minutes to read it then we'd be glad to hear your
f
On 28 November 2012 08:28, Joachim Breitner wrote:
> Open question: What should GHC on Debian do when building binaries,
> given that all libraries are likely available in both ways – shared or
> static. Shared means that all locally built binaries (e.g. xmonad!) will
> suddenly break when the use
On 28 November 2012 03:02, Ian Lynagh wrote:
> We actually have half a plan to fix this, so that a single compilation
> would build both static and dynamic libraries. Most of the work
> (parsing, type checking, optimising) can be shared; it's just the
> codegen phase that needs to be different.
P
On 27/11/2012 14:52, Ian Lynagh wrote:
> GHC HEAD now has support for using dynamic libraries by default (and in
> particular, using dynamic libraries and the system linker in GHCi) for a
> number of platforms.
>
> This has some advantages and some disadvantages, so we need to make a
> decision a
On Tue, Nov 27, 2012 at 9:57 PM, Tyson Whitehead wrote:
> it seemed a big part of the problem is you really need to be able to
> have multiple versions of the same package installed.
>
> At the time, I believe the only way to do this was to include part of
> the hash in the name, but that meant yo
Hi,
> GHC HEAD now has support for using dynamic libraries by default (and in
> particular, using dynamic libraries and the system linker in GHCi) for a
> number of platforms.
I am very happy to hear this news.
I have long been a quiet proponent for defaulting ghc and Cabal to
shared libraries a
On Wed, 2012-11-28 at 00:28 +0100, Joachim Breitner wrote:
> Am Dienstag, den 27.11.2012, 14:52 + schrieb Ian Lynagh:
> > The various issues are described in a wiki page here:
> > http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
> >
> > If you have a few minutes to read it then we
And on 32 bit Linux, which apparently is known to suffer from dynamic...
Though from 20ms to 100ms is more than 30% penalty.
On Wed, Nov 28, 2012 at 3:16 AM, dag.odenh...@gmail.com <
dag.odenh...@gmail.com> wrote:
> That was with GHC 7.4.1, I should add. I didn't measure overall
> performance di
That was with GHC 7.4.1, I should add. I didn't measure overall performance
difference, only the time to finish a command-line invocation.
On Wed, Nov 28, 2012 at 3:11 AM, dag.odenh...@gmail.com <
dag.odenh...@gmail.com> wrote:
> On Tue, Nov 27, 2012 at 3:52 PM, Ian Lynagh wrote:
>
>> This has
On Tue, Nov 27, 2012 at 3:52 PM, Ian Lynagh wrote:
> This has some advantages and some disadvantages, so we need to make a
> decision about what we want to do in GHC 7.8.
>
When I built my CLI app with dynamic linking, the time to run and complete
a command went from 20ms to 100ms, which is part
On Tue, Nov 27, 2012 at 01:34:59PM -0800, Evan Laforge wrote:
> I don't totally understand how ghci loading would work. I assume that
> for external packages it will go load x.so instead of x.a, but what
> about local modules? I assume ghc -c is still going to produce .o
> files, so does that me
Hi,
Am Dienstag, den 27.11.2012, 14:52 + schrieb Ian Lynagh:
> The various issues are described in a wiki page here:
> http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
>
> If you have a few minutes to read it then we'd be glad to hear your
> feedback, to help us in making our dec
Hi,
On Tue, Nov 27, 2012 at 08:15:59PM +, Ian Lynagh wrote:
> > Regarding Question 7 (enable dynamic by default on other platforms)
> > and OpenBSD: as long as it's easy to disable it again, I'll be happy
> > with *any* decision.
>
> It will be easy to turn it off, but depending on the platfo
I don't totally understand how ghci loading would work. I assume that
for external packages it will go load x.so instead of x.a, but what
about local modules? I assume ghc -c is still going to produce .o
files, so does that mean ghci will have to interpret all local moules?
If so, is there a wa
On Tue, Nov 27, 2012 at 08:38:21PM +0100, Matthias Kilian wrote:
> On Tue, Nov 27, 2012 at 02:52:48PM +, Ian Lynagh wrote:
> > The various issues are described in a wiki page here:
> > http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
> >
> > If you have a few minutes to read it th
Hi,
On Tue, Nov 27, 2012 at 02:52:48PM +, Ian Lynagh wrote:
> The various issues are described in a wiki page here:
> http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
>
> If you have a few minutes to read it then we'd be glad to hear your
> feedback, to help us in making our deci
On Tue, Nov 27, 2012 at 12:07:34PM -0500, Stephen Paul Weber wrote:
> Somebody claiming to be Ian Lynagh wrote:
> >On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote:
> >>IIRC, one of the problems with dynamic linking in GHC is that when
> >>the GHC version is different, the ABI can
Somebody claiming to be Ian Lynagh wrote:
On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote:
IIRC, one of the problems with dynamic linking in GHC is that when
the GHC version is different, the ABI can often be different enough
to making such shared libraries incompatible with e
On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote:
> Somebody claiming to be Ian Lynagh wrote:
> >GHC HEAD now has support for using dynamic libraries by default (and in
> >particular, using dynamic libraries and the system linker in GHCi) for a
> >number of platforms.
> >
> >The v
Somebody claiming to be Ian Lynagh wrote:
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
The various issues are described in a wiki page here:
http://hackage.haskell.org/trac
Hi all,
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
This has some advantages and some disadvantages, so we need to make a
decision about what we want to do in GHC 7.8. There
61 matches
Mail list logo
