Do we need a configure check for glibc to cover the memory problem discussed in http://bugzilla.mozilla.org/show_bug.cgi?id=3142 ?

reassigning to briano

This is fairly easy to do (I think) using 'gcc -E - -dM </dev/null' and checking __GNUC__, but is it really needed? What's the background on this bug? I've looked at bug 3142, but I still don't know what this is all about. What compile macros needs to be set (or created) based on the libc version?

glibc needs to be patched to avoid loading dll's multiple times. We should detect this patch at configure time if possible. Dp mailed out to mozilla.builds about this.

moving to m5

changing component to build config

All the information you need to do this is here in a detailed post I made to n.p.m.unix a long time ago: news://news.mozilla.org/36CDBBD4.C3D138FB%40netscape.com news://news.mozilla.org/36CDBCE3.9643C1B3%40netscape.com

so is this done yet? m5 or m6?

I can't get to this right now. I hope to do it before M6, but I don't think it's important enough to delay M5.

where are we with this?

I still don't have this working properly (as far as I can tell, since I don't have any way to test it). Can someone point me at a machine that has this problem (and hasn't been patched yet), or tell me which glibc distributions have this bug (2.0.7? or older ones?).

It looks like the following point release fixed the problem: glibc-2.0.7-32 glibc-devel-2.0.7-32 and a straight install of RH5.2 installs glibc-2.0.7-29 glibc-devel-2.0.7-29 the SparcLinux boxes probably have not been fixed, telnet://sleestack has not, so you could test this there.

if this is fixed, who needs to verify and close this bug?

I just checked in a new Linux-only test for this in configure. I made it non-fatal, such that it just spits out a message about how upgrading glibc will benefit the user, and then continues on like normal. Let me know if it needs any tweaks.

vrfy