Created attachment 377110 [details, diff] Patch to allow udev-212 to build with gcc 4.5.4. Using "gcc --version" of "gcc (Gentoo 4.5.4 p1.2, pie-0.4.7) 4.5.4", sys-fs/udev-212-r1 fails to build, with many errors similar to the following: /var/tmp/portage/sys-fs/udev-212-r1/work/systemd-212/src/shared/util.h: In function 'safe_atolu': /var/tmp/portage/sys-fs/udev-212-r1/work/systemd-212/src/shared/util.h:174:9: error: #pragma GCC diagnostic not allowed inside functions /var/tmp/portage/sys-fs/udev-212-r1/work/systemd-212/src/shared/util.h:174:9: error: #pragma GCC diagnostic not allowed inside functions /var/tmp/portage/sys-fs/udev-212-r1/work/systemd-212/src/shared/util.h:174:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] /var/tmp/portage/sys-fs/udev-212-r1/work/systemd-212/src/shared/util.h:174:1: error: #pragma GCC diagnostic not allowed inside functions I've attached a patch that fixes it. Copying it to /etc/portage/patches/sys-fs/udev-212/udev-gcc45.patch is sufficient to allow udev to build properly (via epatch_user). Perhaps include it in a new ebuild? Or perhaps explicitly require a newer gcc? But it seems silly to require a newer gcc just so it can use a new "_Pragma" construct to hide some warnings...
I can confirm the patch works well to get udev through its compilation phase with gcc (Gentoo 4.5.4 p1.1, pie-0.4.7) 4.5.4 (which fails without the patch). Still there is a problem in the install phase (output given below), according to http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/17006 probably related to dev-libs/gobject-introspection-1.32.1 being too old a version (but on my system absolutely required as some older software does not work with more recent versions of that package), so we seem to be having a missing dependency in addition. With more recent versions of dev-libs/gobject-introspection intentionally being masked on my system, this probably means udev-212 has to be masked as well. /usr/bin/g-ir-scanner --c-include=gudev/gudev.h --namespace=GUdev --nsversion=1.0 --libtool="/bin/sh ./libtool" --include=GObject-2.0 --library=libgudev-1.0.la --pkg-export=gudev-1.0 --warn-all -pipe -Wall -Wextra -Wno-inline -Wundef -Wformat=2 -Wformat-security -Wformat-nonliteral -Wlogical-op -Wsign-compare -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Werror=overflow -Wnested-externs -ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden -ffunction-sections -fdata-sections -fstack-protector --param=ssp-buffer-size=4 -D_GUDEV_COMPILATION -D_GUDEV_WORK_AROUND_DEV_T_BUG -I/dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src -I./src -I/dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev -I./src/gudev /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudev.h /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudevtypes.h /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudevenums.h /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudevenumtypes.h /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudevclient.h /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudevdevice.h /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudevenumerator.h /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudevclient.c /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudevdevice.c /dev/shm/portage/sys-fs/udev-212-r1/work/systemd-212/src/gudev/gudevenumerator.c libgudev-1.0.la --output src/gudev/GUdev-1.0.gir Usage: g-ir-scanner [options] sources g-ir-scanner: error: no such option: -W
we used to carry this in src_prepare() of sys-fs/udev: # compile with older versions of gcc wrt bug #451110 version_is_at_least 4.6 $(gcc-version) || \ sed -i 's:static_assert:alsdjflkasjdfa:' src/shared/macro.h but it was removed because sys-apps/kmod started to require gcc-4.6 minimum, but then later sys-apps/kmod was modified by upstream so it compiles with older gcc again, but the hack was never returned to sys-fs/udev after that i can reapply the sed hack in sys-fs/udev-213 and 9999 if you test it still works
*** This bug has been marked as a duplicate of bug 451110 ***
also, the guideline is that only latest stable gcc is supported, and gcc-4.6 has been stable for a long time, so i'm not sure why you are still using gcc-4.5 do you have a valid use case for gcc-4.5? i mean, if you do, i'll make an effort and apply your patch, but if this just an outdated system that needs an toolchain upgrade, then please just upgrade your toolchain and we are done here
(In reply to Ulrich Fieseler from comment #1) > g-ir-scanner: error: no such option: -W see bug 510864
Strictly speaking, this bug can probably be considered low priority, even though it could be argued that it is not actually a duplicate of bug 451110. For the few people who are still using gcc 4.5 or older, they can just copy my patch into /etc/portage/patches/sys-fs/udev-212/udev-gcc45.patch like I do. ---- For completeness: The systemd people apparently reworked the relevant chunk of code between versions 208 and 212. In the process, they made it less portable: They replaced the decades-old common "do { ... } while(0)" local scope construct with something that depends on a new (gcc-only, 4.6 or greater) _Pragma() construct to hide warnings about declaring variables after statements. The _Pragma() thing is what is breaking. In contrast, bug 451110 is about static_assert. The static_assert is still there in 212 (with different surrounding macros stuff), but for some reason I'm not tripping over that particular problem. Perhaps the build system is no longer defining __USE_ISOC11, or something? See the bottom of /usr/include/assert.h. ---- I intentionally stay a few years behind with gcc for a few non-critical reasons below (I only recently gcc-config'ed version 4.5 instead of 4.4 on some of my machines): 1. I'm a nut about maintaining a high degree of portability in the software I develop. Among other things, I want to avoid accidentally using newer language features until they've had a few years to get implemented by multiple different compilers on multiple different operating systems, and actually deployed to most installations of them... 2. Given that a gcc downgrade is reputed to be difficult, I prefer to stay at least a version behind just to have some maneuvering room if I ever encounter compiler problems (and [slight exaggeration] it still feels like 4.7 was barely stabilized yesterday). Although admittedly the only problems I typically have are from projects not being as portable to older compilers as they could be. (libreoffice has generally been the main culprit, although since it is a "leaf" package, I have just worked around it by using package.env to only use a newer compiler for it. But narrowly configured compiler upgrades don't seem safe for a core package with several reverse dependencies like udev.) 3. Also, I had not known that gentoo suggests that: > [...] the guideline is that only latest stable gcc is supported [...]
Created attachment 380992 [details, diff] Updated patch udev-215 with gcc 4.5.4 Updated patch: bug 451110 is now also affecting me with udev-215 (perhaps some other that affects this became stable?), so here is a version of the patch that fixes both issues.
Thanks for taking the time to write this patch. I'm not adding it to tree, but I still appericiate it. I've unduplicated the bug and updated the $summary so people find the bug and the patch, if they *really* need it. The 4.5.x is considered obsolete, and I still haven't seen a compelling reason to still support it.
Sorry for not having been here in a while. Probably unlike the reporter, I had no intention to request support for gcc 4.5, for me it would suffice to have some message saying that gcc >= 4.6 is required (similar to what libreoffice does) so that no error messages are produced which are hard to track down to a gcc version problem. Note that there are good reasons not to use too recent GCC (in my case more precisely, g++) versions; the well-known boost library contains code that is known to not work with g++ 4.5 or 4.6 (have not tested yet if 4.7 fixes this). Still the dependency on a more recent gobject-introspection does not seem to have been introduced before udev-214 and is therefore still missing in 212-r1.
(In reply to Ulrich Fieseler from comment #9) > Still the dependency on a more recent gobject-introspection does not seem to > have been introduced before udev-214 and is therefore still missing in > 212-r1. Current stable is 215 where it's been fixed, 04 Jun 2014; Samuli Suominen <ssuominen@gentoo.org> udev-213.ebuild, udev-9999.ebuild: Raise gobject-introspection dependency from 1.31.1 to latest stable, which is 1.38, in attempt of solving bug #510864 There are no plans on backporting fixes to 212* anymore, it's considered redudant version, 208* is longterm version kept for 2.6.32 kernel support and >=215 is for everything else, 215 is also the current stable (And this obviously doesn't belong to this bug)
