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....)
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.htm....
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.htm....
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: magnus@therning.org jabber: magnus@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