On Mon, Oct 28, 2013 at 11:01:21PM +0100, Fabien Dubosson wrote: >> We absolutely do need the static libs to be included in the >> generated packages. Ghc 7.6 uses static linking by default and >> thus all our tool packages rely on static libs in order to build >> properly. It could of course be changed but it'd require a change >> to cblrepo to generate PKGBUILDs that uses `depends` rather than >> `makedepends`. > > So I made a proposition (pull request to cblrepo) to explicitly > include the "staticlibs" option in generated PKGBUILD since this is > the GHC default linking (and also because it was suggested by Allan > here: > https://mailman.archlinux.org/pipermail/arch-dev-public/2013-October/025542.html) > > Actually the generated PKGBUILDs seem to already use 'depends' and > not 'makedepends', or am I missing the point?
Look at the generated PKGBUILD for a tool such as `cblrepo` and you'll see what I mean. > I also noticed two points: First it seems the archlinux default idea > is to use dynamic linking: > https://mailman.archlinux.org/pipermail/arch-general/2013-October/034337.html. Indeed, there's been numerous threads on that lately. > Secondly GHC offers the possibility to build and use dynamic > libraries: > http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/using-shared-libs.html. > Based on these two facts, it appears possible to build the haskell > ecosystem on a dynamic library principle. It will of course require > a large refactoring, but does it worth it? It is just curiosity ;) The default for GHC has always been to link statically, so that's where we started. Then we added building of shared libs at one point, but there was never any push to actually use them. After reading the page you point to above (in the GHC 7.6.3 docs) I'm also wondering what flags to give at build time to make an executable use dynamic libs. I had a look at pandoc, which is a package providing both a lib and an exe. It is configured with `--enable-shared` but the executable isn't dynamically linked against the libs it uses: % ldd /usr/bin/pandoc linux-vdso.so.1 (0x00007fffbbb93000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f23e993a000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f23e96d4000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f23e94d0000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f23e92b2000) libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f23e903b000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f23e8d38000) librt.so.1 => /usr/lib/librt.so.1 (0x00007f23e8b30000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f23e891a000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f23e856f000) /lib64/ld-linux-x86-64.so.2 (0x00007f23e9b50000) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus "Sendmail" and "make" are two well known programs that are pretty widely regarded as being debugged into existence. That's why their command languages are so poorly thought out and difficult to learn. It's not just you -- everyone finds them troublesome. -- Peter van der Linden, Expert C Programming, p. 220
pgpk4sW6mL6l8.pgp
Description: PGP signature
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
