ddssff / cabal-debian

Create a Debianization by examining a .cabal file.
Other
16 stars 10 forks source link

spurious linking against libffi and libatomic1 #68

Open jhidding opened 5 years ago

jhidding commented 5 years ago

When I use cabal-debian to build a debian package for an executable, the resulting executable is linked against libffi and libatomic1, whereas the same build using stack build has no such linkage. The debbuild command warns that these libraries are linked against but no calls are made that actually need them.

I run a project called entangled (https://github.com/jhidding/entangled). I use the following Dockerfile to build an installable .deb file:

FROM debian:testing

RUN apt-get update && apt-get install --no-install-recommends -y \
    cabal-debian \
    cabal-install \
    devscripts \
    ghc

RUN apt-get install --no-install-recommends -y \
    build-essential \
    cdbs \
    fakeroot \
    haskell-devscripts

RUN apt-get install --no-install-recommends -y \
    libghc-either-dev \
    libghc-extra-dev \
    libghc-fsnotify-dev \
    libghc-fsnotify-dev  \
    libghc-hspec-dev  \
    libghc-microlens-platform-dev \
    libghc-optparse-applicative-dev \
    libghc-prettyprinter-dev \
    libghc-prettyprinter-ansi-terminal-dev \
    libghc-random-dev \
    libghc-regex-tdfa-dev \
    libghc-terminal-size-dev \
    libghc-uuid-dev

COPY entangled-0.2.0.0.tar.gz /tmp

WORKDIR /tmp
RUN tar xvf entangled-0.2.0.0.tar.gz \
    && cd entangled-0.2.0.0 \
    && cabal-debian -m "Johan Hidding <j.hidding@esciencecenter.nl>" \
        --native -s entangled -e entangled --disable-profiling \
        --disable-haddock --disable-tests \
        --depends "entangled:libatomic1 (>= 8) libc6 (>= 2)" \
    && debuild -us -uc

The resulting binary is linked as:

$ ldd entangled
linux-vdso.so.1 (0x00007ffdb00a2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9cf599d000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9cf5993000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f9cf598e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9cf5989000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9cf5968000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f9cf58e5000)
libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f9cf58d9000)
libffi.so.6 => /lib/x86_64-linux-gnu/libffi.so.6 (0x00007f9cf58cf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9cf570e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9cf5b58000)
ddssff commented 5 years ago

I'm not using cabal-debian heavily these days - is this blocking your use of the package?

jhidding commented 5 years ago

Not really. cabal-debian just makes it very easy to create a Debian package, and I was hoping there's an easy fix. I could dig a bit deeper and see where the dependency creeps in.

ddssff commented 5 years ago

I think libatomic1 is a dependency of Neil Mitchell's extra package, even though I don't actually call the function that uses it.