[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#616494: git-annex: FTBFS on various archs: undefined reference to symbol 'sem_close@@GLIBC_…'

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
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.


Reply to: