| Summary: | gedit-2.4.0 failed: `LC_ALL' undeclared | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Erik Swanson (RETIRED) <erik_swanson> |
| Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Erik Swanson (RETIRED)
2003-09-13 19:33:45 UTC
i can only reproduce this when i use your CFLAGS. try something like "-march=i686 -O2 -pipe" and set "debug" in USE if you want -g. I have exactly the same problem with my CFLAGS="-mcpu=athlon-xp -O3 -pipe" Failed: CFLAGS="-O0 -g -pipe" CFLAGS="" Works: CFLAGS="-march=i686 -O2 -pipe" CFLAGS="-O2 -pipe" Pending (I think its past where it usually dies): CFLAGS="-O2 -g -pipe" More cflags results: Works: CFLAGS="-O -g -pipe" CFLAGS="-O2 -g -pipe" CFLAGS="-O3 -g -pipe" This seems to be a problem somewhat related to CFLAGS indeed. I think there are at least two possible solutions: tweaking compilation flags inside the ebuild (bringing a bit of awkwardness to it, and voiding part of the purpose of this variable unnecessarily), or patching the source, so it correctly includes locale.h (the standard header where LC_ALL is usually in) when needed. I chose the latter option, since I think it makes more sense, the fix is in CVS. Maybe a bug report in Gnome's bugzilla is in order? Thank you very much for bringing this to the attention of Gentoo developers. I get the same result, but ONLY if I use no CFLAGS at all (""). I get different errors otherwise, which are found at bug 28708.
CFLAGS="-march=i686 -O2 -pipe" works for me. Thanks for the work, people :) Joe/Deathwing00 are either of you using gcc3.3 ? I don't believe that the patch is the complete solution. Why would that code only fail on certain CFLAGS, if the header isn't included across all cases ? More so, if the header isn't included, then shouldn't it fail on all cases ? The patch doesnt address the differing CFLAGS affecting the build. And be careful about posting upstream problems to GNOME, if they are Gentoo specific (as usually seen with CFLAGS issues) then they won't be well recieved. *** Bug 28751 has been marked as a duplicate of this bug. *** Hello. Thank you all for your comments. There is in fact a problem when a piece of C code uses setlocale() but doesn't include locale.h. This should come natural to any C coder. Googling for this subject, you can come across lots of examples of this. http://mail.gnome.org/archives/garnome-list/2002-November/msg00061.html http://lists.spine.cx/archives/everybuddy/2002-July/001925.html http://lunar-linux.org/pipermail/lunar.old/2002-March/000033.html (Moreover, it's rather interesting how this problem shows up in a lot of Gnome-related packages. Maybe developers tend to rely on autoconf magic or another headr file which includes locale.h for them?) Why is this an issue influenced by CFLAGS, and why it compiles fine under certain circumstances, I don't really know right now. My guess would be that optimization flags somehow make it compile, but the resulting binaries could be problematic. But then again, I'm not sure. > I don't believe that the patch is the complete solution. Maybe this bug is giving a hint about some deeper issues here that should be studied by the people who develop these packages. But it seems to me that the patch fixes the real problem reported by Erik (it would be nice to hear from him if he have tho chance to test it). > And be careful about posting upstream problems to GNOME (..) I know, I'm familiar with both Gnome's bugzilla and our own. :) Thanks for the notes, Mike, they are very relevant. @Leonardo: I just tested it; the patch does fix the compile failure. @Mike: Why was bug 28751 marked as a duplciate of this one? Assuming there is no root problem, it is a seperate occurance of this _type of_ problem. because, to me, the 2 occurances, where the CFLAGS were common, hints at something else being the problem. my train of thought then, and still now is that "if this is a compile-time error (missing header) then why doesnt it fail for me with 'normal' CFLAGS'". feel free to re-open 28751 if you feel it was hard done by. i'm still skeptical, maybe that's just me. who knows. The patch resolved this bug, and the upstream maintainer has committed the fix to his tree too. Re-closing. Thanks again for the report. |