Hello Simon, On Monday 09 February 2009 10:47, Simon Marlow wrote: > BuildBot Collator wrote: > > > Old unexpected test failures: > > > > conc019 1 tnaur x86 Linux stable > > Thorkil - I thought I'd look at a few of these failures on "tnaur x86 Linux > stable", and it seems you are plagued by > > +can't load .so/.DLL for: rt (/usr/lib/librt.so: symbol > __librt_multiple_threads, version GLIBC_PRIVATE not defined in file > libc.so.6 with link time reference) > > any idea what's wrong there? > > Cheers, > Simon >
For ffi009(ghci) (selected arbitrarily) this happens when loading the unix library: > t...@linux:~/tn/buildbot/ghc/tnaur-x86-linux/tnaur-x86-linux-head/build/testsuite/tests/ghc-regress/ffi/should_run> /home/tn/tn/buildbot/ghc/tnaur-x86-linux/tnaur-x86-linux-head/build/ghc/stage2-inplace/ghc --interactive -fforce-recomp -fglasgow-exts ffi009.hs > GHCi, version 6.11.20090211: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > [1 of 1] Compiling Main ( ffi009.hs, interpreted ) > Ok, modules loaded: Main. > *Main> main > Loading package old-locale-1.0.0.1 ... linking ... done. > Loading package old-time-1.0.0.1 ... linking ... done. > Loading package random-1.0.0.1 ... linking ... done. > Loading package array-0.2.0.1 ... linking ... done. > Loading package filepath-1.1.0.1 ... linking ... done. > Loading package unix-2.3.1.0 ... can't load .so/.DLL for: rt (/usr/lib/librt.so: symbol __librt_multiple_threads, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference) > *Main> I have looked around and found that http://www.redhat.com/archives/rhl-devel-list/2003-August/msg00254.html describes a problem that seems similar: > librt.so TLS issues > > From: Alexander Larsson <alexl redhat com> > To: "rhl-devel-list redhat com" <rhl-devel-list redhat com> > Cc: roland redhat com > Subject: librt.so TLS issues > Date: 21 Aug 2003 12:07:07 +0200 > There was a change in glibc somewhere between 2.3.2-57 and 2.3.2-66 that > adds /usr/lib/librt.so.1 to glibc-devel. The file is just a symlink to > librt.so. This change seems wrong to me, and its causing breakage with > TLS. > > I have an app not linking to librt, but it dlopens a library that links > to librt.so.1. The app gets the tls libc at /lib/tls/libc.so.6, but when > resolving the librt.so.1 DT_NEEDED it first looks in the system library, > finding /usr/lib/librt.so.1. However, following this symlink gets you > /lib/librt.so.1 which is the non-TLS version of librt. This means we > have mismatched librt and libc versions, causing: > > /usr/lib/librt.so.1: symbol __librt_disable_asynccancel, version > GLIBC_PRIVATE not defined in file libc.so.6 with link time reference > > Having the soname librt in /usr/lib just seems wrong to me. What was the > reason for introducing it? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl redhat com alla lysator liu se I have not been able to understand fully what this is about, nor finding the details of any solution. However, it seems clear that incompatible versions of libc.so.6 ("TLS version") and librt.so.1 ("non-TLS version") are being used together, causing the error. But whether this should be fixed by a change in the Linux system setup, a change in the way dlopen searches for libraries, a change in the way dlopen is being called, some combination of these things, or something else entirely, I am unable to tell. In any case, changing the /usr/lib link > lrwxrwxrwx 1 root root 15 Nov 8 2005 librt.so -> /lib/librt.so.1 to > lrwxrwxrwx 1 root root 19 Feb 11 10:36 /usr/lib/librt.so -> /lib/tls/librt.so.1 seems to fix the problem, at least for ffi009(ghci). Best regards Thorkil _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
