[Pkg-haskell-maintainers] Bug#616494: git-annex: FTBFS on various archs: undefined reference to symbol 'sem_close@@GLIBC_…'

[Ian Lynagh]

On Tue, Mar 08, 2011 at 01:58:40PM +0000, Iain Lane wrote:
> On Tue, Mar 08, 2011 at 06:56:03PM +0530, Joachim Breitner wrote:
> >Hi,
> >
> >Am Dienstag, den 08.03.2011, 18:44 +0530 schrieb Joachim Breitner:
> >>But with kfreebsd-amd64, we have one successful and one failing build on
> >>the same machine, fano:
> >>https://buildd.debian.org/fetch.cgi?pkg=ghc;ver=7.0.2-1;arch=kfreebsd-amd64;stamp=1299357096
> >>https://buildd.debian.org/fetch.cgi?pkg=ghc;ver=7.0.2-2;arch=kfreebsd-amd64;stamp=1299584180

The first (successful) build says:

checking for library containing sem_close... none required

> And as the failures come when building the in-tree ghc-pwd copy, it
> looks like we have a misbuild. This is what my explicit -optl-pthread
> hack was to get around — so the ghc-pwd build links correctly.
> 
> I've added Ian (Lynagh) to cc. Ian, do you have any insight here? Do
> we need to add AC_SEARCH_LIBS checks for all sem_* functions to
> libraries/unix/configure.ac? And what about my hacks to explicitly
> link with pthread to bootstrap? (See debian bug #616494 for the
> history).
> 
> I guess as a last resort, we can disable the new
> --no-add-needed/--no-copy-dt-needed-entries stuff in our ghc build.

My guess is that if you don't have the stricter behaviour introduced by
    http://lists.debian.org/debian-devel-announce/2011/02/msg00011.html
then the build will go through and detect that no library is needed, but
if you then try to use the binary on a machine that does have the
stricter behaviour then the compiler won't be able to link anything
using unix.

So using your hack to get GHC built with the strictly-behaving linker on
all platforms should bootstrap the solution, and once all buildds have
the strict behaviour the hack won't be needed any more.


Thanks
Ian