I can't confirm this, but I have reason to suspect that a bug in glibc for mips might be fixed in glibc upstream right now, and we'd like a newer snapshot to be able to verify this/ As it currently stands, attempting to build glibc with gcc-4.3.1 and binutils-2.18 produces a bad lib where the following undefined symbol appears: sh: symbol lookup error: sh: undefined symbol: __gnu_local_gp When using simple programs such as sh, python, etc. It renders the system mostly unusable (tar and basic file commands aren't affected it looks). The symbol, __gnu_local_p, is supposed to be some kind of internal mechanism within the linker, and this error is one of those "it shouldn't happen" cases, but I have received very little feedback from upstream on what the cause might be. I was told that glibc-2.7 and earlier were not certified to be built with gcc-4.3.1, so it's possible this bug was caught early and fixed in 2.8.
that isnt how the snaps work. the 2.8 snaps are from the 2.8 branch, not from the CVS HEAD. nothing has changed in the 2.8 branch since the date we have our ebuild against. that means you'll need to track down the changes in question from HEAD and cut a patch that applies to the 2.8 branch.
That's been the hard part. Trying to find someone that has any idea on what's causing this particular issue. Most people have just told me to stick with gcc-4.1.2 for things. I don't know if it's gcc, the linker, or libc at fault, and Google has very little info, aside from some debian patches to their mklibs package that seems to even remotely address an issue regarding this particular symbol. Is there an easy way to pull CVS Head and make it compatible with the glibc ebuild? If need be, I'll work backwards in CVS until I find something that works.
Which tag from glibc's CVS is our 2.8 ebuild based off of? glibc-2_8-branch or glibc-2_8? I spoke to a glibc developer and he said he gave up trying to get 2.7 to work with gcc-3.4.1. He says his glibc snapshot of 2.8 from about 4 weeks ago worked fine.
Reopening, cause I need extra info pursuant to the Comment #3 so I can track down fixes. Mostly, I want to roll my own glibc 2.8 ebuild using the same procedure the last one was done so I can test it on my Octane and hopefully pin this problem down. Is there any documentation on how the glibc ebuilds are thrown together as far as snapshots are concerned?
glibc-2_8-branch i believe. there have been literally zero changes since April though. maint_pkg_create() in the 2.8 ebuild looks like it might be what you're looking for.
"glibc-2_8-branch" is a branch while "glibc-2_8" is a tag. so snapshots would only come from one of those ... however, we arent rolling our own snaps. upstream already automatically generates them from the branch and that is what we use. regardless, if you did a cvs diff between "glibc-2_8-branch" and "glibc-2_8", i doubt you'd see any changes. like Ryan said, there has literally been 0 activity since it branched. i dont know what glibc snap you're talking about, but the only ones that we look at are the ones here: ftp://sources.redhat.com/pub/glibc/ and if the changes were actually in the branch, we'd already have them
It is possible I may have found the cause of this. It might not be in glibc after all, but a net effect of using gcc-4.3 with glibc, and causing some funk to get install on the system. Recompiling a few applications is making these undefined refs slowly disappear. However, once they're gone, I'm going to re-create and see if this is indeed a problem between gcc-4.3 and glibc and whether there's a specific upgrade path I'll have to take to resolve it. Will update in a few more days...
Rebuilt about 200 packages on the Octane against glibc-2.7-r2 with gcc-4.3.2. That mysterious linker error didn't re-appear there, and I'd be willing to bet it wouldn't appear in 2.8 either. So I'm going to close this. I must've just built something in the wrong order, or it was a bug in gcc-4.3.1.
sounds good ... feel free to elaborate if you ever do track down the root cause of the bug ...
