From fabien.dubosson at gmail.com Fri Nov 1 09:51:49 2013 From: fabien.dubosson at gmail.com (Fabien Dubosson) Date: Fri, 1 Nov 2013 10:51:49 +0100 Subject: [arch-haskell] devtools version problem In-Reply-To: <20131031232005.GC3276@mteis.lan> References: <20131028181210.GB6195@mteis.lan> <20131030061456.GA1007@mteis.lan> <20131031201208.GA1004@mteis.lan> <20131031232005.GC3276@mteis.lan> Message-ID: > I had a look at the change you created and I'm not sure a flag to the > pkgbuild command is a good way to go. I'm much more in favour of > simply making it the way we build, i.e. add > '--enable-executable-dynamic' on all builds of lib packages. Of course, my modifications are for the case where building dynamic executables is not the default way. But obviously if that becomes the default option, adding it on all PKGBUILDs is the simplest thing. > Sure, but I'm not convinced using shared libs is the route to take for > pure executable packages (like cblrepo and git-annex). As long as > pure executable packages are linked statically we'll need the static > libs of course. It's also the case that linking statically is the Ghc > default, which speaks in favour of keeping the static libs. Well, your second argument is pretty unbreakable :) As long as this is the ghc default, static libraries are needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabien.dubosson at gmail.com Fri Nov 1 12:04:44 2013 From: fabien.dubosson at gmail.com (Fabien Dubosson) Date: Fri, 1 Nov 2013 13:04:44 +0100 Subject: [arch-haskell] Dynamic executables and RPATH Message-ID: 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 `pandoc` dynamically this morning, and there is only one issue left (unless I do something wrong?). For dynamic linking, Cabal/GHC embed an RPATH into the executable: $ readelf --dynamic /usr/bin/pandoc [[...]] 0x000000000000000f (RPATH) Library rpath: [/home/fabien/archlinux/habs/haskell-pandoc/src/pandoc-1.12.1/dist/build:/usr/lib/ghc-7.6.3/site-local/zip-archive-0.1.4:/usr/lib/ghc-7.6.3/site-local/zlib-0.5.4.1:/usr/lib/ghc-7.6.3/site-local/utf8-string-0.3.7:/usr/lib/ghc-7.6.3/site-local/digest-0.0.1.2:/usr/lib/ghc-7.6.3/site-local/binary-0.7.1.0:/usr/lib/ghc-7.6.3/site-local/texmath-0.6.4:/usr/lib/ghc-7.6.3/site-local/xml-1.3.13:/usr/lib/ghc-7.6.3/site-local/temporary-1.1.2.4:/usr/lib/ghc-7.6.3/site-local/tagsoup-0.13:/usr/lib/ghc-7.6.3/site-local/random-1.0.1.1:/usr/lib/ghc-7.6.3/process-1.1.0.2:/usr/lib/ghc-7.6.3/site-local/hslua-0.3.7:/usr/lib/ghc-7.6.3/site-local/data-default-0.5.3:/usr/lib/ghc-7.6.3/site-local/data-default-instances-old-locale-0.0.1:/usr/lib/ghc-7.6.3/site-local/data-default-instances-dlist-0.0.1:/usr/lib/ghc-7.6.3/site-local/data-default-instances-containers-0.0.1:/usr/lib/ghc-7.6.3/site-local/data-default-instances-base-0.0.1:/usr/lib/ghc-7.6.3/site-local/data-default-class-0.0.1:/usr/lib/ghc-7.6.3/site-local/base64-bytestring-1.0.0.1:/usr/lib/ghc-7.6.3/site-local/yaml-0.8.5.1:/usr/lib/ghc-7.6.3/site-local/conduit-1.0.8:/usr/lib/ghc-7.6.3/site-local/void-0.6.1:/usr/lib/ghc-7.6.3/site-local/semigroups-0.11:/usr/lib/ghc-7.6.3/site-local/nats-0.1.2:/usr/lib/ghc-7.6.3/site-local/resourcet-0.4.9:/usr/lib/ghc-7.6.3/site-local/mmorph-1.0.0:/usr/lib/ghc-7.6.3/site-local/lifted-base-0.2.1.0:/usr/lib/ghc-7.6.3/site-local/monad-control-0.3.2.2:/usr/lib/ghc-7.6.3/site-local/transformers-base-0.4.1:/usr/lib/ghc-7.6.3/site-local/base-unicode-symbols-0.2.2.4:/usr/lib/ghc-7.6.3/site-local/pandoc-types-1.12.3:/usr/lib/ghc-7.6.3/site-local/highlighting-kate-0.5.5:/usr/lib/ghc-7.6.3/site-local/pcre-light-0.4:/usr/lib/ghc-7.6.3/site-local/blaze-html-0.6.1.1:/usr/lib/ghc-7.6.3/site-local/blaze-markup-0.5.1.5:/usr/lib/ghc-7.6.3/site-local/extensible-exceptions-0.1.1.4:/usr/lib/ghc-7.6.3/directory-1.2.0.1:/usr/lib/ghc-7.6.3/filepath-1.3.0.1:/usr/lib/ghc-7.6.3/site-local/aeson-0.6.2.1:/usr/lib/ghc-7.6.3/site-local/vector-0.10.9.1:/usr/lib/ghc-7.6.3/site-local/primitive-0.5.1.0:/usr/lib/ghc-7.6.3/site-local/unordered-containers-0.2.3.3:/usr/lib/ghc-7.6.3/template-haskell-2.8.0.0:/usr/lib/ghc-7.6.3/pretty-1.1.1.0:/usr/lib/ghc-7.6.3/site-local/syb-0.4.1:/usr/lib/ghc-7.6.3/site-local/hashable-1.2.1.0:/usr/lib/ghc-7.6.3/site-local/dlist-0.5:/usr/lib/ghc-7.6.3/site-local/blaze-builder-0.3.1.1:/usr/lib/ghc-7.6.3/site-local/attoparsec-0.10.4.0:/usr/lib/ghc-7.6.3/containers-0.5.0.0:/usr/lib/ghc-7.6.3/site-local/HTTP-4000.2.8:/usr/lib/ghc-7.6.3/old-time-1.1.0.1:/usr/lib/ghc-7.6.3/site-local/network-2.4.2.0:/usr/lib/ghc-7.6.3/unix-2.6.0.1:/usr/lib/ghc-7.6.3/time-1.4.0.1:/usr/lib/ghc-7.6.3/old-locale-1.0.0.5:/usr/lib/ghc-7.6.3/site-local/parsec-3.1.3:/usr/lib/ghc-7.6.3/site-local/text-0.11.3.1:/usr/lib/ghc-7.6.3/site-local/mtl-2.1.2:/usr/lib/ghc-7.6.3/site-local/transformers-0.3.0.0:/usr/lib/ghc-7.6.3/bytestring-0.10.0.2:/usr/lib/ghc-7.6.3/deepseq-1.3.0.1:/usr/lib/ghc-7.6.3/array-0.4.0.1:/usr/lib/ghc-7.6.3/base-4.6.0.1:/usr/lib/ghc-7.6.3/integer-gmp-0.5.0.0:/usr/lib/ghc-7.6.3/ghc-prim-0.3.0.0:/usr/lib/ghc-7.6.3] [[...]] This is working to find all libraries except one: ` libHSpandoc-1.12.1-ghc7.6.3.so`. The reason is the following: At compile time, cabal first builds the pandoc library, then the pandoc executable which is using this library. But because the library is not installed at this moment (understand: not located in the final place `/usr/lib/ghc-7.6.3/site-local/pandoc-1.12.1/`) the RPATH embeds its *current* location, in my case `/home/fabien/archlinux/habs/haskell-pandoc/src/pandoc-1.12.1/dist/build` (see the output above). So as long as the library is present in this folder, pandoc works, but obviously that is not working to distribute it. I suppose this method is working for cabal-install because the library stays at its place once built, which is not the case here: the library is moved once built. Also I suppose this problem doesn't appear with library-only package, because each package generate only one `*.so` file (as far as I have seen), so no need to link against another library of the same package at build time. Up to my knowledge I see three solutions: 1. Find a way to build and install in two passes, something like separating in haskell-pandoc and haskell-pandoc-libs (first build and install pandoc-libs, then build and install pandoc) - Requires to find a way to create separate PKGBUILDs for the same hackage package. Elegant but complicated solution, so not very convenient. 2. Try to modify the RPATH inside the executable - Seems to be possible, see [3], but complicated and not very elegant solution. 3. Change the linking paradigm to use /etc/ld.so.conf.d/* instead of the embedded RPATH - Requires to put or link all `*.so` libraries into on place, and add a `/etc/ld.so.conf.d/haskell.conf` file to ghc installation. The most tractable solution imho. Does anyone has remarks/suggestions/ideas/solutions about this problem? Best regards, Fabien [1] https://github.com/magthe/cblrepo/commit/de9df07d398d70255c852f4de53e3d14c4eeb0b4 [2] http://www.haskell.org/pipermail/arch-haskell/2013-October/004600.html [3] http://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Sun Nov 3 05:33:35 2013 From: magnus at therning.org (Magnus Therning) Date: Sun, 3 Nov 2013 06:33:35 +0100 Subject: [arch-haskell] Dynamic executables and RPATH In-Reply-To: References: Message-ID: <20131103053335.GA2047@mteis> 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 mailing list [2] and solves some of the cited > problems. I tried to build `pandoc` dynamically this morning, and > there is only one issue left (unless I do something wrong?). You did not do something wrong at all. I was a bit to eager pushing the change and seem to have missed in testing the results of that change properly. > This is working to find all libraries except one: ` > libHSpandoc-1.12.1-ghc7.6.3.so`. The reason is the following: At compile > time, cabal first builds the pandoc library, then the pandoc executable > which is using this library. But because the library is not installed at > this moment (understand: not located in the final place > `/usr/lib/ghc-7.6.3/site-local/pandoc-1.12.1/`) the RPATH embeds its > *current* location, in my case > `/home/fabien/archlinux/habs/haskell-pandoc/src/pandoc-1.12.1/dist/build` > (see the output above). So as long as the library is present in this > folder, pandoc works, but obviously that is not working to distribute it. I > suppose this method is working for cabal-install because the library stays > at its place once built, which is not the case here: the library is moved > once built. Which explains why my crude initial test succeeded, I didn't bother removing the build folder after installation. > Also I suppose this problem doesn't appear with library-only > package, because each package generate only one `*.so` file (as far > as I have seen), so no need to link against another library of the > same package at build time. That seems logical. It also wouldn't be a problem for exe-only packages since then there is no local lib built. > Up to my knowledge I see three solutions: > > 1. Find a way to build and install in two passes, something like > separating in haskell-pandoc and haskell-pandoc-libs (first > build and install pandoc-libs, then build and install pandoc) - > Requires to find a way to create separate PKGBUILDs for the > same hackage package. Elegant but complicated solution, so not > very convenient. > 2. Try to modify the RPATH inside the executable > - Seems to be possible, see [3], but complicated and not very > elegant solution. > 3. Change the linking paradigm to use /etc/ld.so.conf.d/* instead > of the embedded RPATH > - Requires to put or link all `*.so` libraries into on place, > and add a `/etc/ld.so.conf.d/haskell.conf` file to ghc > installation. The most tractable solution imho. > > Does anyone has remarks/suggestions/ideas/solutions about this problem? Well, to me it seems that Cabal is broken here. On `configure` Cabal is told where the built lib will end up so it would be more correct to put in an RPATH to that location rather than to the build location of the lib. I'll point this out on the haskell-cafe (if no one's beat me to it :). /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus If voting could really change things it would be illegal. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From magnus at therning.org Sat Nov 9 19:44:09 2013 From: magnus at therning.org (Magnus Therning) Date: Sat, 9 Nov 2013 20:44:09 +0100 Subject: [arch-haskell] Dynamic executables and RPATH In-Reply-To: <20131103053335.GA2047@mteis> References: <20131103053335.GA2047@mteis> Message-ID: <20131109194409.GA26212@mteis.lan> 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 hard coded ghc version in the path ;-) /M ~~~~ From 6882788bb3df039c9b17a2eef831698030e9cc02 Mon Sep 17 00:00:00 2001 From: Magnus Therning Date: Sat, 9 Nov 2013 20:25:29 +0100 Subject: [PATCH] Deal with Cabal's deficiencies in linking dynamically. With this change PKGBUILDs of libs create symbolic links to the DSO at /usr/lib/ghc-7.6.3/shared. They also modify the rpath of all executables, replacing the one put in place by Cabal with one of a single entry: /usr/lib/ghc-7.6.3/shared. Signed-off-by: Magnus Therning --- src/Util/Translation.hs | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/Util/Translation.hs b/src/Util/Translation.hs index 074d364..3d57b6a 100644 --- a/src/Util/Translation.hs +++ b/src/Util/Translation.hs @@ -219,7 +219,17 @@ instance Pretty ArchPkg where text "ln -s \"/usr/share/doc/${pkgname}/html\" \"${pkgdir}/usr/share/doc/ghc/html/libraries/${_hkgname}\"" <$> text "runhaskell Setup copy --destdir=\"${pkgdir}\"" <$> (maybe empty (\ _ -> text "install -D -m644 \"${_licensefile}\" \"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE\"" <$> - text "rm -f \"${pkgdir}/usr/share/doc/${pkgname}/${_licensefile}\"") licenseFile) + text "rm -f \"${pkgdir}/usr/share/doc/${pkgname}/${_licensefile}\"") licenseFile) <$> + empty <$> + text "mkdir ${pkgdir}/usr/lib/ghc-7.6.3/shared" <$> + text "(cd ${pkgdir}/usr/lib/ghc-7.6.3/shared;" <$> + text " for f in $(find .. -name \\*-ghc7.6.3.so); do" <$> + text " ln -s $f" <$> + text " done" <$> + text ")" <$> + text "for f in ${pkgdir}/usr/bin/*; do" <$> + text " chrpath -r /usr/lib/ghc-7.6.3/shared $f" <$> + text "done" ) <$> char '}' @@ -300,7 +310,7 @@ translate db fa pd = let pkgDesc = synopsis pd url = if null (homepage pd) then "http://hackage.haskell.org/package/${_hkgname}" else (homepage pd) lic = display (license pd) - makeDepends = if hasLib then [] else [ghcVersionDep] ++ calcExactDeps db pd + makeDepends = if hasLib then ["chrpath"] else [ghcVersionDep] ++ calcExactDeps db pd depends = if hasLib then [ghcVersionDep] ++ calcExactDeps db pd else [] extraLibDepends = maybe [] (extraLibs . libBuildInfo) (library pd) install = if hasLib then (apShInstall ap) else Nothing -- 1.8.4.2 ~~~~ -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus There's a big difference between making something easy to use and making it productive. -- Adam Bosworth -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From fabien.dubosson at gmail.com Sun Nov 10 10:41:18 2013 From: fabien.dubosson at gmail.com (Fabien Dubosson) Date: Sun, 10 Nov 2013 11:41:18 +0100 Subject: [arch-haskell] Dynamic executables and RPATH In-Reply-To: <20131109194409.GA26212@mteis.lan> References: <20131103053335.GA2047@mteis> <20131109194409.GA26212@mteis.lan> Message-ID: > > 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 line `/usr/lib/ghc-7.6.3/shared`, and building *all* Haskell executables/libraries with ghc-option `-dynload=deploy` as explained in [1]? The difference is that executables/libraries will *not* contain a RPATH, but instead will search in LD folders. That will solve the hard coded path and remove the dependency to `chrpath`. Also, from my point of view, this is a more elegant solution since everything will be dynamic and looking into only one place to find libraries. If applying that to libraries doesn't enjoy people (or doesn't work), it is also possible to do that only for executables. But in this later case, building an executable with ghc-option `-dynload=deploy` will probably apply to its library as well. To bypass this problem I think that simply removing the RPATH from the executable will have the same effect. But I haven't tested that yet. PS: If you want to try the LD version, don't forget to run `sudo ldconfig`, after putting the `/etc/ld.so.conf.d/haskell.conf` file. Otherwise the new path will not be taken into account. [1] http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/using-shared-libs.html Kind regards, Fabien -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Sun Nov 10 15:43:12 2013 From: magnus at therning.org (Magnus Therning) Date: Sun, 10 Nov 2013 16:43:12 +0100 Subject: [arch-haskell] Dynamic executables and RPATH In-Reply-To: References: <20131103053335.GA2047@mteis> <20131109194409.GA26212@mteis.lan> Message-ID: <20131110154312.GA1025@mteis.lan> 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 `/etc/ld.so.conf.d/haskell.conf` file (attached to `ghc` > package) containing the line `/usr/lib/ghc-7.6.3/shared`, and > building *all* Haskell executables/libraries with ghc-option > `-dynload=deploy` as explained in [1]? Would you verify that passing --ghc-options when configuring a package adds the options to 'ghc-options:' if present in the .cabal file? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Java is, in many ways, C++--. -- M Feldman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From fabien.dubosson at gmail.com Sun Nov 10 21:32:25 2013 From: fabien.dubosson at gmail.com (Fabien Dubosson) Date: Sun, 10 Nov 2013 22:32:25 +0100 Subject: [arch-haskell] Dynamic executables and RPATH In-Reply-To: <20131110154312.GA1025@mteis.lan> References: <20131103053335.GA2047@mteis> <20131109194409.GA26212@mteis.lan> <20131110154312.GA1025@mteis.lan> Message-ID: > 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 GHC warnings. 2. A simple `test-ghc-opts.cabal` file which has a `ghc-options:` to display warnings 3. A `build.sh` script which configures the program with a `ghc-options` to remove the [rpath] of dynamic linking. If both the warnings are displayed and the [rpath] doesn't exist, it means that both ways of giving `ghc-options` are working side by side. It is the case on my computer! But I let you verify my scripts to be sure that I'm doing the test correctly. [1] https://gist.github.com/StreakyCobra/0067d15fd74ebf8bf5e0 Kind regards, Fabien -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Mon Nov 11 05:21:51 2013 From: magnus at therning.org (Magnus Therning) Date: Mon, 11 Nov 2013 06:21:51 +0100 Subject: [arch-haskell] Dynamic executables and RPATH In-Reply-To: References: <20131103053335.GA2047@mteis> <20131109194409.GA26212@mteis.lan> <20131110154312.GA1025@mteis.lan> Message-ID: <20131111052151.GA1015@mteis.lan> 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. A dummy `Main.hs` executable which uses an external library and > also generates GHC warnings. > 2. A simple `test-ghc-opts.cabal` file which has a `ghc-options:` > to display warnings > 3. A `build.sh` script which configures the program with a > `ghc-options` to remove the [rpath] of dynamic linking. > > If both the warnings are displayed and the [rpath] doesn't exist, it > means that both ways of giving `ghc-options` are working side by > side. It is the case on my computer! But I let you verify my scripts > to be sure that I'm doing the test correctly. > > [1] https://gist.github.com/StreakyCobra/0067d15fd74ebf8bf5e0 Excellent, then that is indeed a better route than the one I embarked on. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus But whereas I previously held for Java a cordial dislike borne of having only a cursory notion of how it worked, now my dislike for the language can no longer be called at all "cordial", for familiarity has bred contempt. -- tom Christiansen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From magnus at therning.org Fri Nov 15 21:49:19 2013 From: magnus at therning.org (Magnus Therning) Date: Fri, 15 Nov 2013 22:49:19 +0100 Subject: [arch-haskell] Dynamic executables and RPATH In-Reply-To: <20131111052151.GA1015@mteis.lan> References: <20131103053335.GA2047@mteis> <20131109194409.GA26212@mteis.lan> <20131110154312.GA1025@mteis.lan> <20131111052151.GA1015@mteis.lan> Message-ID: <20131115214919.GA2425@mteis.lan> 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 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 GHC warnings. > > 2. A simple `test-ghc-opts.cabal` file which has a `ghc-options:` > > to display warnings > > 3. A `build.sh` script which configures the program with a > > `ghc-options` to remove the [rpath] of dynamic linking. > > > > If both the warnings are displayed and the [rpath] doesn't exist, it > > means that both ways of giving `ghc-options` are working side by > > side. It is the case on my computer! But I let you verify my scripts > > to be sure that I'm doing the test correctly. > > > > [1] https://gist.github.com/StreakyCobra/0067d15fd74ebf8bf5e0 > > Excellent, then that is indeed a better route than the one I embarked > on. Another proposal here: http://is.gd/EbUJXu- /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From fabien.dubosson at gmail.com Sun Nov 17 20:09:33 2013 From: fabien.dubosson at gmail.com (Fabien Dubosson) Date: Sun, 17 Nov 2013 21:09:33 +0100 Subject: [arch-haskell] Dynamic executables and RPATH In-Reply-To: <20131115214919.GA2425@mteis.lan> References: <20131103053335.GA2047@mteis> <20131109194409.GA26212@mteis.lan> <20131110154312.GA1025@mteis.lan> <20131111052151.GA1015@mteis.lan> <20131115214919.GA2425@mteis.lan> Message-ID: > 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/lib/ghc-7.6.3/shared;" <$> > text " for f in $(find .. -name \\*-ghc7.6.3.so); do" <$> But that's just cosmetic :-) I think it is time now to test all this from A to Z! So I would suggest to also create a `dynlinking` branch on the `habs` repository that would contain the GHC's changes (add a `haskell.conf` file, add a call to `ldconfig` in the PKGBUILD). This will let people (or at least us, I don't know if any other person is following this thread ;) the opportunity to test the proposal completely, from the build of GHC to the use of built executables and libraries, with both habs and cblrepo proposed changes. If that succeeds, it will be possible to merge the changes in the main repo (and eventually look further to propose this change to Arch devs that maintains Haskell packages?!?). Kind regards, Fabien -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Mon Nov 25 20:27:09 2013 From: magnus at therning.org (Magnus Therning) Date: Mon, 25 Nov 2013 21:27:09 +0100 Subject: [arch-haskell] Dynamic executables and RPATH In-Reply-To: References: <20131103053335.GA2047@mteis> <20131109194409.GA26212@mteis.lan> <20131110154312.GA1025@mteis.lan> <20131111052151.GA1015@mteis.lan> <20131115214919.GA2425@mteis.lan> Message-ID: <20131125202709.GA21803@mteis.lan> 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 > > text "mkdir ${pkgdir}/usr/lib/ghc-7.6.3/shared" <$> > > text "(cd ${pkgdir}/usr/lib/ghc-7.6.3/shared;" <$> > > text " for f in $(find .. -name \\*-ghc7.6.3.so); do" <$> > > But that's just cosmetic :-) > > I think it is time now to test all this from A to Z! So I would > suggest to also create a `dynlinking` branch on the `habs` > repository that would contain the GHC's changes (add a > `haskell.conf` file, add a call to `ldconfig` in the PKGBUILD). This > will let people (or at least us, I don't know if any other person is > following this thread ;) the opportunity to test the proposal > completely, from the build of GHC to the use of built executables > and libraries, with both habs and cblrepo proposed changes. I'm currently attempting to re-build all of the packages with these changes in place. You can try them out by adding the following (temporary) repo: [haskell-testing] Server = http://xsounds.org/~haskell/testing/\$arch /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. -- R.P. Feynman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: