| Summary: | emerging gnome-applets-1.4.0.5 failed: pasting "&" and "LoadGraph" does not give a valid preprocessing token | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Selecter <selecter> |
| Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | dberkholz, gentoo-bugs, howard_b_golden, sparc |
| Priority: | Lowest | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Proposed patch to correct preprocessor macro.
Updated ebuild using the proposed patch. |
||
|
Description
Selecter
2005-01-24 04:25:09 UTC
https://wwwlistbox.cern.ch/earchive/atlas-sw-bugs/msg01132.html The ## preprocessor directive should only be used when catenating alphanumerical strings to create new tokens. Gcc 3.3 is more strict than gcc 3.2 in the parsing of the code, and treats this violation of the grammar as an error. Gcc 3.2 let it slip through. I could not emerge gcc 3.2 (using 3.3, 3.4) - so there is no temporary workaround for me. Sad... sad... gcc -DIN_GCC -O -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/gcc-3.2.3-r4/work/gcc-3.2.3/gcc -I/var/tmp/portage/gcc-3.2.3-r4/work/gcc-3.2.3/gcc/. -I/var/tmp/portage/gcc-3.2.3-r4/work/gcc-3.2.3/gcc/config -I/var/tmp/portage/gcc-3.2.3-r4/work/gcc-3.2.3/gcc/../include \ -c /var/tmp/portage/gcc-3.2.3-r4/work/gcc-3.2.3/gcc/c-parse.c -o c-parse.o c-p8864.c:349:20: attempt to use poisoned "malloc" c-p8864.c: In function `yy_stack_print': c-p8864.c:2157: warning: traditional C rejects ISO C style function definitions c-p8864.c: In function `yy_reduce_print': c-p8864.c:2183: warning: traditional C rejects ISO C style function definitions c-p8864.c: In function `yysymprint': c-p8864.c:2299: warning: traditional C rejects ISO C style function definitions c-p8864.c: In function `yydestruct': c-p8864.c:2336: warning: traditional C rejects ISO C style function definitions c-p8864.c: In function `yyparse_1': c-p8864.c:2403: warning: traditional C rejects ISO C style function definitions make[2]: *** [c-parse.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/gcc-3.2.3-r4/work/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/var/tmp/portage/gcc-3.2.3-r4/work/build/gcc' make: *** [bootstrap-lean] Error 2 Created attachment 59314 [details, diff]
Proposed patch to correct preprocessor macro.
I removed what appeared to be unnecessary ## concatenators. After this change,
it works for me.
shouldn't it become the following then to keep the intended functionality ? I'm not very familiar with this directive. #define ADD_PROPERTIES(x,y) multiload_property_object_list = g_list_append (multiload_property_object_list, gnome_property_object_new (& x ## Property_Descriptor, & multiload_properties. ## y )) Created attachment 59450 [details]
Updated ebuild using the proposed patch.
Updated ebuild using the proposed patch. Works for me.
Patch and updated ebuild work on SPARC. Can this be fixed please ? It needs to be marked stable in order to be able to mark stable the latest gtk-perl which depends on it. Thanks I'd really like to see my suggestion in comment #3 tested, it seems closer to the original code. Re: Comment #3 and comment #7: foser, as I read the documentation of the ## concatenator, your suggestion is syntactically invalid because it would create a token consisting of "." concatenated with the y argument. The problem is that "." is ALREADY a token and the concatenated expression isn't. Please notice the original bug report where the compiler complained about such a concatenation: main.c:213:39: pasting "." and "netload" does not give a valid preprocessing token I believe that the patch I submitted is correct as is. Howard I read the doc, but that is what it seems to do, legal or not. The question was if it compiles/works or not. Re: Comment #9: foser, are you from Missouri? (The "show me" state for non-US readers.) ;-) Here are the results I got using your proposed definition: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I. -DGNOMELOCALEDIR=\""/usr/share/locale"\" -I -I/usr/include/gnome-1.0 -DNEED_GNOMESUPPORT_H -I/usr/lib/gnome-libs/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -I/usr/include/gtk-1.2 -I/usr/X11R6/include -I/usr/include/gnome-1.0 -DNEED_GNOMESUPPORT_H -I/usr/lib/gnome-libs/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -I/usr/include/gtk-1.2 -I/usr/X11R6/include -I/usr/include/libcapplet1 -I/usr/include/libgtop-1.0 -DHAVE_LIBGTOP_SMP -DHAVE_LIBGTOP_SYSINFO -I/usr/include/gnome-1.0 -DNEED_GNOMESUPPORT_H -I/usr/lib/gnome-libs/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -I/usr/include/gtk-1.2 -I/usr/X11R6/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -march=athlon-xp -O2 -pipe -fstack-protector -Wall -Wunused -c main.c main.c:210:1: pasting "." and "cpuload" does not give a valid preprocessing token main.c:211:1: pasting "." and "memload" does not give a valid preprocessing token main.c:212:1: pasting "." and "swapload" does not give a valid preprocessing token main.c:213:1: pasting "." and "netload" does not give a valid preprocessing token main.c:214:1: pasting "." and "loadavg" does not give a valid preprocessing token make: *** [main.o] Error 1 This is with gcc (GCC) 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110-r2, ssp-3.4.3.20050110-0, pie-8.7.7). To reiterate Selecter's comment #1: "The ## preprocessor directive should only be used when catenating alphanumerical strings to create new tokens. Gcc 3.3 is more strict than gcc 3.2 in the parsing of the code, and treats this violation of the grammar as an error. Gcc 3.2 let it slip through." In other words, you could write x ## Property_Descriptor, which will concatenate the value of the x argument with the string "Property_Descriptor" returning a single string token. However, "." is a token already, so you can't concatenate it with any string, since this would give you TWO tokens, not one. Apparently, earlier GCC's let you do this, but it's not how the ## operator is defined, and they have made the compiler catch these errors in gcc-3.4 (and maybe gcc-3.3). Howard Yes I asked you to show me. I don't know what older gcc's produced for code, but apparently they did let this trough and if it does the way i think it does, this patch changes the functionality of the bit with undefined consequences. That is what I'm worried about, not if it 'compiles or not'. Re: Comment #11: foser, I understand your concern. However, I don't have the time or facilities to test it as thoroughly as you are looking for. Perhaps another approach is to refer the bug upstream? However, in looking at the codebase on the Gnome CVS, I see that the code changed greatly after gnome-1.4, so I wonder if anyone still cares about gnome-1.4 bugs? Please let me know if you want me to try anything specific. Otherwise, I'll just leave this as a "proposed patch" that you will do what you wish with. It works for me. Howard gnome 1.4 is unmaintained upstream. are you still having this problem? In the meantime 1.4.0.5 is no longer installed here, but 2.10.1 no response from reporter |
