On Sun, Dec 22, 2013 at 06:56:11PM -0500, Ben Gamari wrote:

Ian Lynagh writes:

...

On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote:

...

DYNAMIC_BY_DEFAULT = YES

Dynamic-by-default was a previous experiment to get GHCi to use the system linker. We now use dynamic-too instead.

Causing GHCi to use the system linker is indeed my intent. Given the currently rather broken state of the ARM runtime linker it seems like the easiest way to get ARM supported as somewhat-first-class citizen is to use the system linker. `DYNAMIC_BY_DEFAULT` provides an easy way to accomplish this.

You shouldn't need dynamic-by-default. It should Just Work in HEAD, both unregisterised and registerised. Thanks Ian

I think part of what Ian is saying is that the default config for a Perf build for HEAD will build the dylib versions of all the libraries. Or am I not understanding the question? eg: see the default make file https://github.com/ghc/ghc/blob/master/mk/build.mk.sample#L55-L75 On Mon, Dec 23, 2013 at 12:59 PM, Ben Gamari wrote:

Ian Lynagh writes:

...

You shouldn't need dynamic-by-default. It should Just Work in HEAD, both unregisterised and registerised.

Just to clarify, how does one configure GHCi to use dynamic linking now? Should I interpret your message to mean that it is already configured this way? Where in the tree is this configured?

To be perfectly clear, I want to ensure that dynamic linking is always preferred over linking static objects with the RTS linker. Will this happen as things stand? How does GHCi decide how to load a library? Is this the role of GhcDynamic?

I'm still not really sure why `DYNAMIC_BY_DEFAULT` should be causing the problems I'm observing. It seems to me that it is functionally equivalent to passing the `-dynamic` flag as they both simply add `WayDyn` to DynFlag's `ways` list. Do you have any idea where they might differ?

Cheers,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

why would the RTS linker be used? I'm not understanding that piece. I thought static linking and dynamic linking both use the system linkers now. Are you meaning the rts linker use for ghci in <= 7.6? On Mon, Dec 23, 2013 at 1:08 PM, Ben Gamari wrote:

Carter Schonwald writes:

...

I think part of what Ian is saying is that the default config for a Perf build for HEAD will build the dylib versions of all the libraries. Or am I not understanding the question?

eg: see the default make file https://github.com/ghc/ghc/blob/master/mk/build.mk.sample#L55-L75

Yes, I understand this. That being said, it will also build static versions. On ARM these static libraries should be avoided as the RTS's linker is still quite broken. Therefore I'd like to ensure that dynamic linking is used whenever possible.

Cheers,

- Ben

On 23/12/13 17:59, Ben Gamari wrote:

Ian Lynagh writes:

...

You shouldn't need dynamic-by-default. It should Just Work in HEAD, both unregisterised and registerised.

Just to clarify, how does one configure GHCi to use dynamic linking now?

You set DYNAMIC_GHC_PROGRAMS=YES (which is the default on supported platforms). This causes GHC itself to be built with -dynamic, which in turn causes GHCi to look for and to load the dynamic versions of packages. Cheers, Simon

Should I interpret your message to mean that it is already configured this way? Where in the tree is this configured?

To be perfectly clear, I want to ensure that dynamic linking is always preferred over linking static objects with the RTS linker. Will this happen as things stand? How does GHCi decide how to load a library? Is this the role of GhcDynamic?

I'm still not really sure why `DYNAMIC_BY_DEFAULT` should be causing the problems I'm observing. It seems to me that it is functionally equivalent to passing the `-dynamic` flag as they both simply add `WayDyn` to DynFlag's `ways` list. Do you have any idea where they might differ?

Cheers,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs