Look at the generated PKGBUILD for a tool such as `cblrepo` and you'll see what I mean.
Hum, I looked again but they seem to use already `depends`. There is 233 packages in habs, and 218 have empty `makedepends`: $ cd habs $ cblrepo pkgbuild $(cblrepo build base|tail -n +2) $ ls */PKGBUILD | wc -l 233 $ grep -R "makedepends=()" */PKGBUILD | wc -l 218 $ grep -R "makedepends=()" */PKGBUILD haskell-abstract-deque/PKGBUILD:makedepends=() haskell-abstract-par/PKGBUILD:makedepends=() haskell-aeson/PKGBUILD:makedepends=() haskell-anansi/PKGBUILD:makedepends=() [[...]] haskell-xmonad/PKGBUILD:makedepends=() haskell-yaml/PKGBUILD:makedepends=() haskell-zip-archive/PKGBUILD:makedepends=() haskell-zlib/PKGBUILD:makedepends=()
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)
The flag "--enable-shared" generates the shared libraries. The flag "-dynamic" builds executable against these libraries. I managed to build pandoc with shared libraries (and it worked, with a small hack, see problem at the end of the message): $ ldd /usr/bin/pandoc linux-vdso.so.1 (0x00007fff819fe000) libHSpandoc-1.12.1-ghc7.6.3.so => /usr/lib/ghc-7.6.3/shared/ libHSpandoc-1.12.1-ghc7.6.3.so (0x00007fd3929ec000) libHSzip-archive-0.1.4-ghc7.6.3.so => /usr/lib/ghc-7.6.3/shared/ libHSzip-archive-0.1.4-ghc7.6.3.so (0x00007fd39279c000) libHSzlib-0.5.4.1-ghc7.6.3.so => /usr/lib/ghc-7.6.3/shared/ libHSzlib-0.5.4.1-ghc7.6.3.so (0x00007fd392577000) [[...]] libHStransformers-0.3.0.0-ghc7.6.3.so => /usr/lib/ghc-7.6.3/shared/ libHStransformers-0.3.0.0-ghc7.6.3.so (0x00007fd3869d6000) libHSinteger-gmp-0.5.0.0-ghc7.6.3.so => /usr/lib/ghc-7.6.3/shared/ libHSinteger-gmp-0.5.0.0-ghc7.6.3.so (0x00007fd3867c5000) libHSmtl-2.1.2-ghc7.6.3.so => /usr/lib/ghc-7.6.3/site-local/mtl-2.1.2/ libHSmtl-2.1.2-ghc7.6.3.so (0x00007fd386598000) librt.so.1 => /usr/lib/librt.so.1 (0x00007fd386390000) libutil.so.1 => /usr/lib/libutil.so.1 (0x00007fd38618d000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fd385f89000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fd385d6b000) libHSdeepseq-1.3.0.1-ghc7.6.3.so => /usr/lib/ghc-7.6.3/deepseq-1.3.0.1/ libHSdeepseq-1.3.0.1-ghc7.6.3.so (0x00007fd385b62000) libHSarray-0.4.0.1-ghc7.6.3.so => /usr/lib/ghc-7.6.3/array-0.4.0.1/ libHSarray-0.4.0.1-ghc7.6.3.so (0x00007fd3858c1000) libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007fd38564a000) libffi.so.6 => /usr/lib/libffi.so.6 (0x00007fd385442000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fd38513f000) /lib64/ld-linux-x86-64.so.2 (0x00007fd3937a3000) I have modified cblrepo to add a flag "--dynamic" to the "pkgbuild" command to generate a PKGBUILD with dynamic linking: $ cblrepo pkgbuild --dynamic pandoc See: https://github.com/StreakyCobra/cblrepo/commit/677fe94c311c9e71f0ad99c1f7ee3... I'll propose that as a pull request when all will be working. The current problem ----------------------------- There is still a small problem: Referencing the shared libraries. As stated at the bottom of [1], there is two ways: 1. By embedding a RPATH into the executable. 2. Using LD_LIBRARY_PATH (or equivalently and better /etc/ld.so.conf.d/*) to specify libraries paths. The first solution is system dependent, and also less elegant from my point of view. So I focused on the second. Sadly the current hierarchy of Haskell packages doesn't place all shared libraries in the same folder, but in separate folders of the form: /usr/lib/ghc-<version>/[site-local]/<package>-<version>/<sharedLibraryName>.so It is unfeasible to reference all these folders (even more with the version in the folder name). So I actually just made a small hack: a "/usr/lib/ghc-7.6.3/shared" folder and soft-links of all "*.so" inside. Then I added a new "/etc/ld.so.conf.d/haskell.conf" file containing the line: /usr/lib/ghc-7.6.3/shared and run `ldconfig` to update the libraries paths. Do you see any better way to reference these libraries? If no I suggest to put (or link) all "*.so" libraries either in "/usr/lib" or in another folder on a specific place on the system. It is also possible to add, if it is needed, a "/etc/ld.so.conf.d/haskell.conf" file to a new package like "haskell-runtime" and make all Haskell package depends on. [1] http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/using-shared-libs.htm...