I'm going to make one small adjustment to the GC code now: adding GC_no_dls = 1 to the GC intialization code.
This will prevent libgc from scanning the static data areas of dynamic libraries, which seems to cause problems on FC2, and in any case is unnecessary.
Ideally we want the most conservative gc configuration that is reasonably possible; this should bring us a step closer.
-mental
On Sun, 29 Aug 2004 13:43:09 -0400, MenTaLguY wrote:
I'm going to make one small adjustment to the GC code now: adding GC_no_dls = 1 to the GC intialization code.
This will prevent libgc from scanning the static data areas of dynamic libraries, which seems to cause problems on FC2, and in any case is unnecessary.
I've located the problem. It was a combination of bugs in boehm GC (which I've reported) and apbuild. We were forcing dl_iterate_phdrs to be "undefined" but as this is a weak symbol this did not cause a link failure as it was meant to, but rather subtly forced libgc onto a much less used codepath which apparently makes some bad assumptions about ELF headers.
I've fixed apbuild for this specific case, though the real fix is for apbuild to ignore weak symbols as all uses of them should be checked anyway. Not doing so is almost certainly a bug in the application.
I'm respinning the nightly build now to confirm the fix works. There's no need for alarm, standard builds for Fedora should work fine. This is just a teething problem with autopackage.
In any case, dl_iterate_phdr has been around for a while, at least since Red Hat 7.2 and I doubt we care anymore about systems older than that. We should probably bump the minimum glibc version autopackage binaries require to something more modern, maybe Red Hat 8 generation systems.
Problem is that it's difficult to get a feel for how many people are using what generation of Linux systems. I know developers tend to overestimate it: there are still new installs of Red Hat 9 and even 8 being carried out but maybe glibc 2.3.x is a reasonable baseline to target from now on.
thanks -mike
On Mon, 30 Aug 2004 16:44:16 +0100, Mike Hearn wrote:
I'm respinning the nightly build now to confirm the fix works. There's no need for alarm, standard builds for Fedora should work fine. This is just a teething problem with autopackage.
The nightly builds are working perfectly again :) Even the crash-after-select bug has gone in them, for some reason.
Bryce, I have to disappear again for a week, so it might be worth taking the autopackage for the 0.39 release down and just leaving the nightly builds. I'm still no closer to understanding what is going wrong with that build, but as it seems to be gone in the CVS nightlies I'm tempted to write it off to gremlins.
It should be noted that Fedora Core ncurses broke tput a bit so the build of autopackage the nightlies and 0.39 are against doesn't render the command line frontend quite right. It's a minor aesthetic issue fixed in CVS, but some people have noticed it and wondered what's up.
thanks -mike
On Mon, 30 Aug 2004, Mike Hearn wrote:
Bryce, I have to disappear again for a week, so it might be worth taking the autopackage for the 0.39 release down and just leaving the nightly builds. I'm still no closer to understanding what is going wrong with that build, but as it seems to be gone in the CVS nightlies I'm tempted to write it off to gremlins.
Okay, I've commented out the link. Let me know when to reactivate it.
Thanks, Bryce
participants (3)
-
Bryce Harrington
-
MenTaLguY
-
Mike Hearn