tags 617759 - moreinfo
quit
Jonathan Nieder wrote:
> $ icedove; echo $?
> /usr/lib/icedove/icedove-bin: symbol lookup error:
> /usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc
> 127
I tried reproducing this with upstream glibc. I'm way too lazy to
rebuild icedove in a sysroot, so that meant:
git checkout 9f94d2ea
cd ..
mkdir glibc-build
cd glibc-build
../glibc/configure --prefix=$HOME/opt/glibc
make install
In a root shell, kept open for safety:
cd ~jrn/src/glibc-build
cp -dp /lib/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2.backup
ln -sf $(pwd)/elf/ld.so /lib/ld-linux-x64-64.so.2
As an ordinary user:
LD_LIBRARY_PATH=$HOME/opt/glibc:/usr/local/lib:/usr/lib:/lib
export LD_LIBRARY_PATH
icedove
Worked great --- icedove opened without trouble. So probably either
the bug is caused by a Debian or eglibc patch, or it is related to
ld.so.cache. Next step will be to try the patched source.
A less puzzling finding: LD_BIND_NOW avoids trouble, too.
The icedove source says
/**
* Static helper routines to manage memory. These routines allow easy
access
* to xpcom's built-in (global) nsIMemory implementation, without
needing
* to go through the service manager to get it. However this requires
clients
* to link with the xpcom DLL.
*
* This class is not threadsafe and is intented for use only on the main
* thread.
*/
Maybe the warning is relevant? But this does not feel like a race
(especially with a narrow window like that between the following "if"
and "return")
if (!xpcomFunctions.allocFunc)
return nsnull;
return xpcomFunctions.allocFunc(size);
since the result of running icedove is the same every time.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
