I'm trying to get some binaries running on NixOS, and I ran into a weird situation when trying to get ldd to find libpython2.7.so.1.0 and other libs.
$ ldd lldb
./lldb: /nix/store/5rjfisjzz6vgwmgf7zx25yd9p6rfs0zy-ncurses-6.2-abi5-compat/lib/libtinfo.so.5: no version information available (required by ./lldb)
./lldb: /nix/store/5rjfisjzz6vgwmgf7zx25yd9p6rfs0zy-ncurses-6.2-abi5-compat/lib/libtinfo.so.5: no version information available (required by /nix/store/nn8pr7xzam0rz7fq95x9dpi087xazsnv-theos/share/theos/toolchain/linux/iphone/usr/bin/./../lib/liblldb.so.10git)
linux-vdso.so.1 (0x00007ffd57b80000)
libpthread.so.0 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libpthread.so.0 (0x00007f921e821000)
liblldb.so.10git => /nix/store/nn8pr7xzam0rz7fq95x9dpi087xazsnv-theos/share/theos/toolchain/linux/iphone/usr/bin/./../lib/liblldb.so.10git (0x00007f9215c3c000)
libz.so.1 => /nix/store/1l4r0r4ab3v3a3ppir4jwiah3icalk9d-zlib-1.2.11/lib/libz.so.1 (0x00007f9215c1f000)
librt.so.1 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/librt.so.1 (0x00007f9215c12000)
libdl.so.2 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libdl.so.2 (0x00007f9215c0d000)
libtinfo.so.5 => /nix/store/5rjfisjzz6vgwmgf7zx25yd9p6rfs0zy-ncurses-6.2-abi5-compat/lib/libtinfo.so.5 (0x00007f9215ba7000)
libm.so.6 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libm.so.6 (0x00007f9215a66000)
libstdc++.so.6 => /nix/store/c9f15p1kwm0mw5p13wsnvd1ixrhbhb12-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x00007f9215891000)
libgcc_s.so.1 => /nix/store/c9f15p1kwm0mw5p13wsnvd1ixrhbhb12-gcc-10.3.0-lib/lib/libgcc_s.so.1 (0x00007f9215875000)
libc.so.6 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libc.so.6 (0x00007f92156b0000)
/nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/ld-linux-x86-64.so.2 => /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib64/ld-linux-x86-64.so.2 (0x00007f921e843000)
libpython2.7.so.1.0 => not found
libncurses.so.5 => not found
libform.so.5 => not found
libpanel.so.5 => not found
libuuid.so.1 => not found
libedit.so.2 => not found
libxml2.so.2 => not found
There are quite a few missing, but let's focus on libpython2.7.so.1.0. When we check the RUNPATH of ld64,
$ readelf -d ld64 | rg RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/nix/store/c9f15p1kwm0mw5p13wsnvd1ixrhbhb12-gcc-10.3.0-lib/lib:/nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib:/nix/store/xvyzi7cr0icnyavi5pm9rywjc4d8l7sx-libedit-20210714-3.1/lib:/nix/store/yxflij8cg4fgnzqmda91jx4d94jvkjf5-util-linux-2.37.2-lib/lib:/nix/store/370lxynzkmwrk8685jx9p2vgh7h0xp2h-libxml2-2.9.12/lib:/nix/store/5rjfisjzz6vgwmgf7zx25yd9p6rfs0zy-ncurses-6.2-abi5-compat/lib:/nix/store/nvx0l614cv661i5zz6w3j3y2w1xzppv1-python-2.7.18/lib:/nix/store/7344a20iqaja6i2qdz2xrgzy28rgnz5p-util-linux-2.37.2-lib/lib:/nix/store/1l4r0r4ab3v3a3ppir4jwiah3icalk9d-zlib-1.2.11/lib:$ORIGIN/../lib]
it contains /nix/store/nvx0l614cv661i5zz6w3j3y2w1xzppv1-python-2.7.18/lib, which has our desired lib,
$ file /nix/store/nvx0l614cv661i5zz6w3j3y2w1xzppv1-python-2.7.18/lib/libpython2.7.so.1.0
/nix/store/nvx0l614cv661i5zz6w3j3y2w1xzppv1-python-2.7.18/lib/libpython2.7.so.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
I'm not sure how this is possible. The executable is also 64-bit, as we can see here:
$ file lldb
lldb: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped
I'm not sure how this is possible.
There is a big difference between RUNPATH and RPATH: the former applies only to the binary itself (in this case, only to the lldb binary), the latter applies to the binary and all its dependencies.
Effectively using RUNPATH forces all binaries participating in the (dynamic) link to be linked correctly (to specify their own RUNPATH so that every one of their (recursive) dependencies is found).
What you observe is possible if:
lldb does not itself depend on libpython.2.7.so.1.0 and
one of lldbs dependencies does depend on on libpython.2.7.so.1.0 and
that dependency itself does not have a RUNPATH in which libpython.2.7.so.1.0 can be found.
You can verify that 1) is true with readelf -d ./lldb | grep libpython (I predict there will be no output).
If 1) is true, we know that 2 is true because libpython shows up in ldd output. You can find which of lldbs direct dependencies this is by going through them one by one (you can see them in the output from readelf -d lldb | grep NEEDED).
Once you found a dependency which needs libpython, you can confirm 3) by using readelf -d $direct_dependency | grep R.*PATH.
Related
Will two libraries together produce a third library that does not even exist?
Try it here
Make sure there are icu and g++ on your machine
Output
ldd out1:
linux-vdso.so.1 (0x00007ffd5cdaf000)
liblcf.so.0 => /home/aleck099/.local/lib/liblcf.so.0 (0x00007ff200600000)
libicuuc.so.72 => /usr/lib/libicuuc.so.72 (0x00007ff200200000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff1ffe00000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007ff200518000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007ff2008a1000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007ff1ffc19000)
libicui18n.so.71 => not found
libicuuc.so.71 => not found
libicudata.so.71 => not found
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007ff200874000)
libicudata.so.72 => /usr/lib/libicudata.so.72 (0x00007ff1fde00000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff2008ea000)
ldd out2:
linux-vdso.so.1 (0x00007ffdfed78000)
libicui18n.so.72 => /usr/lib/libicui18n.so.72 (0x00007fa088000000)
libicuuc.so.72 => /usr/lib/libicuuc.so.72 (0x00007fa087c00000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa087800000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fa08834d000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fa087fe0000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fa087619000)
libicudata.so.72 => /usr/lib/libicudata.so.72 (0x00007fa085800000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fa08845e000)
You can see that three "not found"s in the ldd output of out1
They are even duplicates of existing icu libraries
How could this happen?
Other information
both clang and gcc produce the same result
liblcf.so is built from easyrpg
It looks like the link command used to create out1 picked up symbols from two different versions of the ICU library: libicuuc.so.71 and libicuuc.so.72. The 71 vs 72 is the version number. Those appear to be two different versions of the shared library that were both in the linker's library path. It's "not found" at ldd time because one copy is not in the runtime shared library search path, and even if it was mixing both is probably a bad idea.
The solution is likely to inspect your link command and ensure the -L options only include one version/copy of the ICU library.
EDIT: Linking with verbosity enabled (g++ -v option) will provide additional information about the libraries and paths being used.
Note that it's possible that some of the shared libraries pulled in by out1 are transitively pulling in the (non-existent) libicuuc.so.71. Comparing your two ldd executable outputs, I would be suspicious of /home/aleck099/.local/lib/liblcf.so.0 (and possibly /usr/lib/libexpat.so.1) that only appear in out1. The following command may help:
$ ldd /home/aleck099/.local/lib/liblcf.so.0 /usr/lib/libexpat.so.1
I use rust 1.34 and 1.35. Currently it links to GLIBC_2.18.
How can I limit cargo build to link GLIBC up to version 2.14?
Unfortunately, you can't. Not really, and not consistently. This is a problem with any binary that dynamically links to GLIBC. You can try setting up multiple GLIBC versions and linking to one, or you can try patching the resulting binary, but it's inconsistent and impractical.
So what are some practical options?
Compile Statically
By using MUSL instead of GLIBC we can compile statically.
To install the MUSL target with rustup (assuming x86_64 architecture):
$ rustup component add rust-std-x86_64-unknown-linux-musl
And to use it when compiling:
$ cargo build --target x86_64-unknown-linux-musl
This is the easiest method by far, but won't always work, especially when using native libraries, unless they can also be compiled statically.
Make a VM That Has an Older Version
This is a common approach. By using an OS with an outdated, GLIBC the binary will have GLIBC symbols that are compatible with it.
Use a Docker Container
This is probably the most convenient method, in my opinion. If you have Docker, you can just compile your project with a container that contains an old GLIBC. View the Rust contianer's README for compilation instructions. The command below will compile a project using Rust 1.67 and GLIBC 2.28 (which comes with buster):
$ docker run --rm --user "$(id -u)":"$(id -g)" -v "$PWD":/usr/src/myapp -w /usr/src/myapp rust:1.67-buster cargo build --release
I compiled this on Ubuntu 22.04 and tested it on Ubuntu 20.04.
To test further, I made sure the binary relied on another dynamic library (OpenSSL) and here's the result of ldd ./mybinary after compiling with the Docker container:
$ ldd ./mybinary
linux-vdso.so.1 (0x00007ffd98fdf000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fe49e248000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe49e22d000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe49e223000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe49e200000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe49e0b1000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe49e0ab000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe49deb7000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe49ea30000)
And this is what it looks like without the container:
$ ldd ./mybinary
linux-vdso.so.1 (0x00007ffd5d7b7000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fe85564c000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe85562c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe855545000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe85531d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe855f98000)
This question already has answers here:
Multiple glibc libraries on a single host
(11 answers)
Closed 6 years ago.
I need to make ELF binary file to use another version of libc.so for scientific purposes. I tried to do it with LD_PRELOAD and patchelf utility, but then binary does not run with an errors like:
./a.out: error while loading shared libraries: libc-2.15.so: cannot open shared object file: No such file or directory or Segmentation fault (core dumped).
I think that it is because I need another version of ld.so.
What is most efficient way to make binary use my version of libc?
EDIT: I do not have source code of binary.
EDIT: Error message edited. No SELinux, no AppArmor.
For me it looks that you did not spend the whole path to the new libc variant.
I did the following:
ldd example
linux-vdso.so.1 (0x00007ffe9c087000)
libstdc++.so.6 => /opt/linux-gnu_6.1.0/lib64/libstdc++.so.6 (0x00007f0cef872000)
libm.so.6 => /lib64/libm.so.6 (0x00007f0cef56f000)
libgcc_s.so.1 => /opt/linux-gnu_6.1.0/lib64/libgcc_s.so.1 (0x00007f0cef359000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0ceef98000)
/lib64/ld-linux-x86-64.so.2 (0x000055ca3cb92000)
LD_PRELOAD=/tmp/bug_libc.so ldd example
linux-vdso.so.1 (0x00007ffc2cff8000)
/tmp/bug_libc.so (0x00007f56a1358000)
libstdc++.so.6 => /opt/linux-gnu_6.1.0/lib64/libstdc++.so.6 (0x00007f56a0f9a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f56a0c98000)
libgcc_s.so.1 => /opt/linux-gnu_6.1.0/lib64/libgcc_s.so.1 (0x00007f56a0a82000)
/lib64/ld-linux-x86-64.so.2 (0x00005605c8a7a000)
If I replace with a non valid libc a got a different error message. Only if I gave the wrong path like:
LD_PRELOAD=/tmp/bug_libc.so2 ldd go
ERROR: ld.so: object '/tmp/bug_libc.so2' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/tmp/bug_libc.so2' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
linux-vdso.so.1 (0x00007ffedcde4000)
libstdc++.so.6 => /opt/linux-gnu_6.1.0/lib64/libstdc++.so.6 (0x00007f3ae2188000)
libm.so.6 => /lib64/libm.so.6 (0x00007f3ae1e85000)
libgcc_s.so.1 => /opt/linux-gnu_6.1.0/lib64/libgcc_s.so.1 (0x00007f3ae1c6f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3ae18ae000)
/lib64/ld-linux-x86-64.so.2 (0x000055df54aae000)
Maybe you have some other problem by accessing your replacement libc-file.
Check the access flags on the file and also check if SELinux or AppArmor or other protection stops loading libc in your environment. Because replacing libc opens a security hole it is a candidate for SELinux & Co!
And you should check always with ldd first. Maybe your new libc requires some more (older) variants of other libs which can not be found on your system. Normaly libc did not require other libs, but I have no idea what game you are playing. Whatever: ldd gives you a more detailed answer to the things which are going on in the library loading phase.
EDIT: segfault
If you get segfault, you typically have compiled your application with incompatible header files. You have to compile with the headers which comes with the libc version you want to use. If you compile against your system headers for system libc and run any incompatible version of precompiled libc, you get any kind of memory errors by accessing wrong data structures.
This answer explains why LD_PRELOAD can not work, and suggests solutions.
I tried to do it with LD_PRELOAD and patchelf utility
It's not clear whether your use of patchelf touched only DT_RPATH, only PT_INTERP, or both. You need to do both.
I know this question has been asked a lot, but the problem remains fo me:
I have a 64bits ELF executable that I am trying to run on my Kali VM, but it keeps telling me that the file doesn't exist.
The solution most of the time for this problem is the difference of architecture, but my Kali is x86-64:
$ uname -m
x86_64
like the file (named '8') that I am trying to execute:
file 8
8: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, BuildID[sha1]=0xf3b096c69086131b091d1805894fde4fae0537a0, stripped
EDIT: Error:
$ chmod +x 8
$ ./8
bash: ./8: No such file or directory
EDIT 2 : lld:
linux-vdso.so.1 => (0x00007fffe37fe000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f680fac8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f680f73c000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f680f343000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f680f13f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f680ef28000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f680fd49000)
I tried to install the 32 bits library to be sure, but it didn't solve anything neither. I also tried it on my Ubuntu, same issues.
Has anybody an idea on ho to run it ? Here is a link to it if some of you want to try on other architectures: https://www.dropbox.com/s/s3ucka4ufd00zmy/8?dl=0
bash: ./8: No such file or directory
This is caused by the file having an elf interpreter which is not installed on your system.
You can find out which elf interpreter your file is compiled with by running
readelf -l ./8 | grep interpreter
I am guessing that you have /lib/ld-linux-x86-64.so.2 compiled in, whereas the standard 64-bit elf interpreter is /lib64/ld-linux-x86-64.so.2.
The best fix is to correct the build script for your executable (it has something like -Wl,--dynamic-linker=/lib/ld-linux-x86-64.so.2 in it).
Alternatively, creating a symlink:
sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib
will also fix the problem.
I am having issues linking to a Haskell library we wrote. It goes wrong on Ubuntu, but not on Arch Linux. The error on Ubuntu we get is this:
/usr/bin/ld: warning: libHSdeepseq-1.3.0.0-ghc7.4.1.so, needed by /usr/lib/ghc/containers-0.4.2.1/libHScontainers-0.4.2.1-ghc7.4.1.so, not found (try using -rpath or -rpath-link)
/usr/lib/ghc/containers-0.4.2.1/libHScontainers-0.4.2.1-ghc7.4.1.so: undefined reference to 'deepseqzm1zi3zi0zi0_ControlziDeepSeq_zdfNFDataArrayzuzdcrnf1_info'
The issue seems to be caused by the fact that libHScontainers-0.4.2.1-ghc7.4.1.so is incorrectly linked as one can see by the output of ldd:
ldd /usr/lib/ghc/containers-0.4.2.1/libHScontainers-0.4.2.1-ghc7.4.1.so
linux-vdso.so.1 => (0x00007fffe95a2000)
libHSdeepseq-1.3.0.0-ghc7.4.1.so => not found
libHSbase-4.5.0.0-ghc7.4.1.so => not found
libHSghc-prim-0.2.0.0-ghc7.4.1.so => not found
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f89a5a59000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f89a569a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f89a5fd8000)
Apparently the dependent libraries can not be found. They are installed. However if I do the same on Arch:
ldd /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/libHSdeepseq-1.3.0.2-ghc7.8.3.so
linux-vdso.so.1 (0x00007fff09dfe000)
libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007fb8d3e96000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fb8d3b91000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fb8d3988000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fb8d3784000)
libffi.so.6 => /usr/lib/libffi.so.6 (0x00007fb8d357b000)
libHSarray-0.5.0.0-ghc7.8.3.so => /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/../array-0.5.0.0/libHSarray-0.5.0.0-ghc7.8.3.so (0x00007fb8d32e1000)
libHSbase-4.7.0.1-ghc7.8.3.so => /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/../base-4.7.0.1/libHSbase-4.7.0.1-ghc7.8.3.so (0x00007fb8d2967000)
libHSinteger-gmp-0.5.1.0-ghc7.8.3.so => /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/../integer-gmp-0.5.1.0/libHSinteger-gmp-0.5.1.0-ghc7.8.3.so (0x00007fb8d274c000)
libHSghc-prim-0.3.1.0-ghc7.8.3.so => /usr/lib/ghc-7.8.3/deepseq-1.3.0.2/../ghc-prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.so (0x00007fb8d24cf000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fb8d212c000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fb8d1f10000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007fb8d435f000)
The libraries are found.
As suggested I can solve this on Ubuntu by using -rpath in the application we try to link to the Haskell library. But this means that we have to do this for every Haskell package which seems wrong to me.
We can also fix this by adding a line to /etc/ld.so.conf.d/ghc.conf. But this also has to be done for every package and is not user-friendly.
A few questions I have:
What is the correct way to fix this?
Why are the packages in ghc-dynamic incorrectly linked?
Why is the linker able to find libHScontainers-0.4.2.1-ghc7.4.1.so but not libHSdeepseq-1.3.0.0-ghc7.4.1.so?
I strongly suspect that this is because the Haskell libraries installed by ghc have the locations of their dependencies (the RPATH field of their ELF header; you can verify using readelf -d) defined in terms of $ORIGIN. When library X depends on library Y, library X can indicate that library Y should be found in a location relative to its own location by using $ORIGIN. This is supported by the dynamic linker, but is not supported by the static linker.
(I'm speculating here:) Your library will define the location of its direct dependencies (in your case, I'm guessing, this includes containers) in terms of its own RPATH, which is not in terms of $ORIGIN. This is why the linker can find those, but not its transitive dependencies (again, I'm guessing, this includes deepseq in your case).
So why the difference between Arch Linux and Ubuntu? (Speculating further.) This is because unlike on Arch Linux, Ubunbu's linker uses --as-needed by default. You see, ghc will link your library against all its dependencies (including transitive ones), but then the linker will omit some of those dependencies because it doesn't directly depend on them. You could verify this by relinking with --no-as-needed.
Note that these errors by the static linkers really aren't errors, but warnings: it tries to resolve symbols, but it can't; but the dynamic linker will be able to anyway. So you can instruct the linker to ignore these errors (--unresolved-symbols=ignore-all) and all should be well.
I've been battling with adding explicit support in Cabal for generating Haskell libraries for use in C programs, and found the same problem. See https://github.com/haskell/cabal/pull/2540#issuecomment-95984067 for details.