> I've abandoned this attempt at the moment. I got stuck on building
> gtk. I haven't looked closely at it, but it seems to build some
> helper binary as a first step, before building the package itself.
> This helper refused to link properly with dynamic libs. I don't
> really have time or patienc
On Mon, Nov 25, 2013 at 09:27:09PM +0100, Magnus Therning wrote:
> On Sun, Nov 17, 2013 at 09:09:33PM +0100, Fabien Dubosson wrote:
> > > Another proposal here: http://is.gd/EbUJXu-
> >
> > That seems a good solution. I have 2 suggestions:
> >
> > - Remove the `chrpath` dependency which is not n
On Sun, Nov 17, 2013 at 09:09:33PM +0100, Fabien Dubosson wrote:
> > Another proposal here: http://is.gd/EbUJXu-
>
> That seems a good solution. I have 2 suggestions:
>
> - Remove the `chrpath` dependency which is not needed
> - Use a ${_ghcversion}="ghc-7.6.3" variable to replace in
> > te
> Another proposal here: http://is.gd/EbUJXu-
That seems a good solution. I have 2 suggestions:
- Remove the `chrpath` dependency which is not needed
- Use a ${_ghcversion}="ghc-7.6.3" variable to replace in
> text "mkdir ${pkgdir}/usr/lib/ghc-7.6.3/shared" <$>
> text "(cd ${pkgdir}/usr
On Mon, Nov 11, 2013 at 06:21:51AM +0100, Magnus Therning wrote:
> On Sun, Nov 10, 2013 at 10:32:25PM +0100, Fabien Dubosson wrote:
> > > Would you verify that passing --ghc-options when configuring a package
> > > adds the options to 'ghc-options:' if present in the .cabal file?
> >
> > With plea
On Sun, Nov 10, 2013 at 10:32:25PM +0100, Fabien Dubosson wrote:
> > Would you verify that passing --ghc-options when configuring a package
> > adds the options to 'ghc-options:' if present in the .cabal file?
>
> With pleasure. I made a «dummy» program to verify that (files here
> [1]):
>
> 1.
> Would you verify that passing --ghc-options when configuring a package
> adds the options to 'ghc-options:' if present in the .cabal file?
With pleasure. I made a «dummy» program to verify that (files here [1]):
1. A dummy `Main.hs` executable which uses an external library and also
generates
On Sun, Nov 10, 2013 at 11:41:18AM +0100, Fabien Dubosson wrote:
> >
> > Any comments? (Besides the hard coded ghc version in the path ;-)
> >
>
> Hum, one question (that may solve the hard coded path ;-) :
>
> If the shared libraries need anyway to be in a `shared` folder, why
> not using a `/e
>
> Any comments? (Besides the hard coded ghc version in the path ;-)
>
Hum, one question (that may solve the hard coded path ;-) :
If the shared libraries need anyway to be in a `shared` folder, why not
using a `/etc/ld.so.conf.d/haskell.conf` file (attached to `ghc` package)
containing the lin
This patch shows how I propose dealing with Cabal's inability to build
dynamically linked installable executables.
In short:
- Create links to all DSOs from /usr/lib/ghc-7.6.3/shared.
- Rewrite rpath of executables to only contain
/usr/lib/ghc-7.6.3/shared.
Any comments? (Besides the ha
On Fri, Nov 01, 2013 at 01:04:44PM +0100, Fabien Dubosson wrote:
> Hi,
>
> On the road of dynamic linking for Haskell executables, Magnus has
> pushed a commit [1] on `cblrepo` yesterday. This commit adds the
> cabal flag `--enable-executable-dynamic`. It follows a previous
> discussion on this ma
Hi,
On the road of dynamic linking for Haskell executables, Magnus has pushed a
commit [1] on `cblrepo` yesterday. This commit adds the cabal flag
`--enable-executable-dynamic`. It follows a previous discussion on this
mailing list [2] and solves some of the cited problems. I tried to build
`pando
12 matches
Mail list logo