| Summary: | sys-apps/systemd fails to compile: with error: redefinition of 'struct ia64_fpreg' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Émeric Maschino <emeric.maschino> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | emeric.maschino, ia64, systemd |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | IA64 | ||
| OS: | Linux | ||
| URL: | http://sourceware.org/bugzilla/show_bug.cgi?id=762 | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=439188 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 478076 | ||
| Attachments: |
systemd-201 build log
systemd-201 ebuild environment |
||
Created attachment 355376 [details]
systemd-201 build log
Created attachment 355378 [details]
systemd-201 ebuild environment
Failed emerge logs of systemd-204 and systemd-206-r1 also available if helpful. I don't know if it is supposed to run on ia64, probably is a good idea file this bug on the upstream tracker (In reply to Émeric Maschino from comment #0) > In file included from /usr/include/asm/ptrace.h:58:0, > from /usr/include/linux/ptrace.h:78, > from /usr/include/linux/audit.h:29, > from > /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/shared/linux/ > seccomp-bpf.h:26, > from > /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/core/execute.c:41: > /usr/include/asm/fpu.h:57:8: error: redefinition of 'struct ia64_fpreg' > /usr/include/bits/sigcontext.h:32:8: note: originally defined here > In file included from Ouch, this looks bad. Like a conflict in system headers. Maybe include order or something like this. > /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/core/execute.c:41: > 0: > /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/shared/linux/ > seccomp-bpf.h:56:3: warning: #warning "Platform does not support seccomp > filter yet" [-Wcpp] > /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/core/execute.c: > In function 'setup_output': > /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/core/execute.c: > 343:57: warning: declaration of 'fileno' shadows a global declaration > [-Wshadow] > make[2]: *** [src/core/libsystemd_core_la-execute.lo] Error 1 > > As warning message from seccomp-bpf.h implies, is it because "Enable seccomp > to safely compute untrusted bytecode" is missing from "Processor type and > features" in current kernel (3.8.13) configuration? No, I think the warning means that systemd doesn't support seccomp on IA64 at all. Not sure if that is really relevant. Could you please report the bug upstream (to http://bugs.freedesktop.org/, project 'systemd')? Alternatively, I can proxy it for you. (In reply to Agostino Sarubbo from comment #4) > I don't know if it is supposed to run on ia64, probably is a good idea file > this bug on the upstream tracker (In reply to Michał Górny from comment #5) > Could you please report the bug upstream (to http://bugs.freedesktop.org/, > project 'systemd')? Alternatively, I can proxy it for you. I've bisected it: https://bugs.freedesktop.org/show_bug.cgi?id=67960 You've got two for one ;-) Indeed, while bisecting the present issue, I've hit another problem that I've filed in a separate bug report [1] as I cannot check whether it's still there in current systemd source code, since the present issue prevents me from verifying. Now, the real question is: how did the Wizards of Debian manage to successfully compile systemd-204 for ia64? Indeed, I can find ia64 precompiled packages [2] and looking at the Debian patch list, I frankly doubt that the only one included in the list can solve the present issue: diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c index 77d98ea..973f905 100644 --- a/src/core/dbus-socket.c +++ b/src/core/dbus-socket.c @@ -205,7 +205,7 @@ DBusHandlerResult bus_socket_message_handler(Unit *u, DBusConnection *c, DBusMes { "org.freedesktop.systemd1.Socket", bus_socket_properties, s }, { "org.freedesktop.systemd1.Socket", bus_exec_context_properties, &s->exec_context }, { "org.freedesktop.systemd1.Socket", bus_kill_context_properties, &s->kill_context }, - { "org.freedesktop.systemd1.Socket", bus_unit_properties, u }, + { "org.freedesktop.systemd1.Socket", bus_unit_cgroup_properties, u }, { NULL, } }; diff --git a/units/systemd-tmpfiles-setup-dev.service.in b/units/systemd-tmpfiles-setup-dev.service.in index f029285..764da01 100644 --- a/units/systemd-tmpfiles-setup-dev.service.in +++ b/units/systemd-tmpfiles-setup-dev.service.in @@ -14,4 +14,5 @@ ConditionCapability=CAP_MKNOD [Service] Type=oneshot +RemainAfterExit=yes ExecStart=@rootbindir@/systemd-tmpfiles --prefix=/dev --create Émeric [1] https://bugs.freedesktop.org/show_bug.cgi?id=67961 [2] http://snapshot.debian.org/archive/debian/20130725T034520Z/pool/main/s/systemd/systemd_204-2_ia64.deb (In reply to Émeric Maschino from comment #6) > I've bisected it: https://bugs.freedesktop.org/show_bug.cgi?id=67960 > > Now, the real question is: how did the Wizards of Debian manage to > successfully compile systemd-204 for ia64? Well, this finally has nothing to do with systemd, but with a 10-year old bug in glibc [1]. Since Debian ships eglibc, that explain why systemd can be successfully compiled there. Émeric [1] http://sourceware.org/bugzilla/show_bug.cgi?id=762 Will reassign to our glibc maintainers to see if the bug can be fixed instead ;) (If this bug is causing systemd to not work at all on ia64, looks major enough to not ignore it) (In reply to Pacho Ramos from comment #8) > Will reassign to our glibc maintainers to see if the bug can be fixed > instead ;) > > (If this bug is causing systemd to not work at all on ia64, looks major > enough to not ignore it) Oops, you were quicker than me! Indeed, in the meantime, I've filed a separate generic bug against glibc [1] in order to track [2] in Gentoo. Set to major, as other ebuilds may fail the same way. So, maybe [3] can be marked as depends on [1]? Émeric [1] https://bugs.gentoo.org/show_bug.cgi?id=480528 [2] http://sourceware.org/bugzilla/show_bug.cgi?id=762 [3] https://bugs.gentoo.org/show_bug.cgi?id=480218 *** Bug 480528 has been marked as a duplicate of this bug. *** bug 439188 contains a workaround that maybe would be tested in systemd. Of course the best option would be to really fix the issue... but vapier will know much more for sure as he is also upstream developer (In reply to Pacho Ramos from comment #11) > bug 439188 contains a workaround that maybe would be tested in systemd. Of > course the best option would be to really fix the issue... but vapier will > know much more for sure as he is also upstream developer From [1], it seems that SpanKY is the upstream ia64/glibc maintainer. Or are you referring to systemd upstream? Émeric [1] https://bugs.gentoo.org/show_bug.cgi?id=439188#c8 (In reply to Émeric Maschino from comment #12) > From [1], it seems that SpanKY is > the upstream ia64/glibc maintainer. > [1] https://bugs.gentoo.org/show_bug.cgi?id=439188#c8 OK, from what I understand [1], SpanKY and vapier is the same developer ;-) BTW, as implied in [2], set importance to major. Emeric [1] http://forums.gentoo.org/posting.php?mode=quote&p=5063820 [2] https://bugs.gentoo.org/show_bug.cgi?id=480218#c8 Vapier, do you think something like used for audit could be adapted to systemd? sys-process/audit/files/audit-2.1.3-ia64-compile-fix.patch (Until it's solved in glibc side I mean) Émeric, maybe you could try to adapt: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-process/audit/files/audit-2.1.3-ia64-compile-fix.patch?view=markup The idea is to create fixup.h header and inherit it where needed Vapier, until the real fix lands glibc, why isn't that "fixup.h" workaround header provided by our glibc to not need to repeat it for every package needing it? Hi Pachos, (In reply to Pacho Ramos from comment #15) > Émeric, maybe you could try to adapt: > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-process/audit/ > files/audit-2.1.3-ia64-compile-fix.patch?view=markup > > The idea is to create fixup.h header and inherit it where needed Unfortunately, this doesn't work in the present case. As outlined by vapier in [1], "that fixes the linux/audit.h issue" but "the ia64 ptrace.h suckage still exists"... Émeric [1] http://sourceware.org/bugzilla/show_bug.cgi?id=762#c6 (In reply to Pacho Ramos from comment #16) > Vapier, until the real fix lands glibc, why isn't that "fixup.h" workaround > header provided by our glibc to not need to repeat it for every package > needing it? Well, I'm a little bit reluctant to patch dozen/hundred of programs to work around what I consider (maybe wrongly) a bug in the glibc headers. Why has this structure been redefined in glibc? For portability reason with other OSes? Vapier, as the ia64 glibc maintainer, what's your opinion on this issue? And how is it that eglibc doesn't seem to be affected by this one, as Debian Team successfully compiled systemd 204 for Jessie release? Furthermore, when this problem will be solved, perhaps... one day... in the future... not so far..., we would have to remember all the programs that were patched with the fixup.h workaround and unpatch them. Interesting memories challenge ;-) Émeric (In reply to Émeric Maschino from comment #18) while it is certainly wrong for programs to have to work around this (the bug needs sorting out in the kernel/glibc side), i think you're overstating the # of programs out there that utilize ptrace.h. it's certainly on the low end of "dozens". (In reply to SpanKY from comment #19) > while it is certainly wrong for programs to have to work around this (the > bug needs sorting out in the kernel/glibc side), i think you're overstating > the # of programs out there that utilize ptrace.h. it's certainly on the > low end of "dozens". OK. So, will this problem be fixed in the kernel/glibc side? Émeric, still around? What sys-kernel/linux-headers version did you try? Could you try with newer versions? >=3.8 should be enough if Mike's patch fixes it: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=c0a3a20b6c4b5229ef5d26fd9b1c4b1957632aa7 (I thought you were running 3.9 but just saw in your emerge --info that you had 3.7 version of linux-headers) my kernel headers fix was just for linux/audit.h usage. the existing ptrace.h logic is still broken. posted https://sourceware.org/ml/libc-alpha/2014-01/msg00082.html upstream. Well, Debian people told me that they were able to compile systemd with that update in kernel headers (I mean that seemed that fix was enough for at least compiling systemd, even not being the complete fix for the general issue) Hi,
Was away from keyboard some time. Reconnecting now, so happy new year!
And to start with, good news: I've successfully recompiled systemd-208-r2 with linux-headers-2.9 and my ia64 workstation is now happily booting systemd :-)
I don't know which fix [1] or [2] made it possible, but thanks for the changes.
Should I switch bug status to RESOLVED?
BTW, would it then be possible to keyword ~ia64?
Émeric
[1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=c0a3a20b6c4b5229ef5d26fd9b1c4b1957632aa7
[2] https://sourceware.org/ml/libc-alpha/2014-01/msg00082.html
(In reply to Émeric Maschino from comment #25) Was meaning linux-headers-3.9. Sorry! Émeric Thanks for testing, will go to bug 478076 for the keywording work and leave this for letting Vapier track the main issue if he wants (thanks for your glibc patch vapier!) Émeric -> regarding keywording, please go to: https://bugs.gentoo.org/show_bug.cgi?id=497254 https://bugs.gentoo.org/show_bug.cgi?id=497252 and tell there if they work ok on ia64 as they are needed by systemd too Thanks! let's roll with this then (In reply to SpanKY from comment #28) > let's roll with this then Great! Does it mean that workaround as in [1] can be reverted? Émeric [1] https://bugs.gentoo.org/show_bug.cgi?id=439188 (In reply to Émeric Maschino from comment #29) any hacks the audit package carries can be dropped (In reply to SpanKY from comment #30) > (In reply to Émeric Maschino from comment #29) any hacks the audit package > carries can be dropped OK. So, should I reopen bug #439188 or open a new bug report in order to drop the audit hack? Is there a list of ebuilds where such hacks were applied? You know, the "low end of dozens" we were talking about in comment #19 ;-) Émeric (In reply to Émeric Maschino from comment #31) probably be simpler to just re-open that bug i'm not aware of any other package that can do with cleanup ... the ia64_fpreg bug w/ptrace.h has been there since the start of the ia64 port and will only be fixed with the glibc-2.19 release. so if you delete the workarounds for it, you can't build against older glibc releases. maybe in a few years people won't care about older ia64 installs and then they can get cleaned up. glibc-2.18 includes the fixed reg namespace: http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.18/00_all_0018-ia64-add-__-prefix-to-pt_all_user_regs-ia64_fpreg-BZ.patch?rev=1.1 (In reply to SpanKY from comment #33) > glibc-2.18 includes the fixed reg namespace: > http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.18/00_all_0018-ia64- > add-__-prefix-to-pt_all_user_regs-ia64_fpreg-BZ.patch?rev=1.1 Just to be sure that I fully understand, any hacks the audit package carries can be dropped with glibc >= 2.18, not with older glibc, right? Émeric (In reply to Émeric Maschino from comment #34) the audit hacks are to workaround a specific broken version of the kernel headers, not glibc. so they can probably be dropped now. |
Though not keyworded yet (hence the reason?), systemd cannot be emerged on ia64: In file included from /usr/include/asm/ptrace.h:58:0, from /usr/include/linux/ptrace.h:78, from /usr/include/linux/audit.h:29, from /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/shared/linux/seccomp-bpf.h:26, from /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/core/execute.c:41: /usr/include/asm/fpu.h:57:8: error: redefinition of 'struct ia64_fpreg' /usr/include/bits/sigcontext.h:32:8: note: originally defined here In file included from /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/core/execute.c:41:0: /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/shared/linux/seccomp-bpf.h:56:3: warning: #warning "Platform does not support seccomp filter yet" [-Wcpp] /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/core/execute.c: In function 'setup_output': /var/tmp/portage/sys-apps/systemd-201/work/systemd-201/src/core/execute.c:343:57: warning: declaration of 'fileno' shadows a global declaration [-Wshadow] make[2]: *** [src/core/libsystemd_core_la-execute.lo] Error 1 As warning message from seccomp-bpf.h implies, is it because "Enable seccomp to safely compute untrusted bytecode" is missing from "Processor type and features" in current kernel (3.8.13) configuration? Reproducible: Always Steps to Reproduce: 1.Unmask systemd 2.emerge --ask systemd 3. Actual Results: emerge --ask systemd failed during compile phase Expected Results: emerge --ask systemd should successfully install systemd Here's my emerge --info 'sys-apps/systemd' (for systemd-201) Portage 2.1.12.2 (default/linux/ia64/13.0/desktop/gnome, gcc-4.6.3, glibc-2.15-r3, 3.8.13-gentoo ia64) ================================================================= System Settings ================================================================= System uname: Linux-3.8.13-gentoo-ia64-Madison-with-gentoo-2.2 KiB Mem: 24989776 total, 22085904 free KiB Swap: 1999856 total, 1999856 free Timestamp of tree: Wed, 07 Aug 2013 22:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.5, 3.2.5-r1, 3.3.2-r1 dev-util/cmake: 2.8.10.2-r2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.6.3, 4.7.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo x-my_ebuilds ACCEPT_KEYWORDS="ia64" ACCEPT_LICENSE="* -@EULA" CBUILD="ia64-unknown-linux-gnu" CFLAGS="-mtune=itanium2 -O2 -pipe" CHOST="ia64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-mtune=itanium2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gentoo.modulix.net/gentoo/" LANG="fr_FR.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/my_ebuilds" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa berkdb branding bzip2 cairo cdda cdr cli colord consolekit cracklib crypt cups cxx dbus dri dts dvdr eds encode evo exif fam firefox flac fortran gdbm gif gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk ia64 iconv introspection ipv6 jpeg lcms ldap libnotify libsecret mad mng modules mp3 mp4 mpeg mudflap nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support qt4 readline sdl session socialweb spell ssl startup-notification svg tcpd tiff truetype udev udisks unicode upower usb vorbis wxwidgets xcb xml xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-4" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON Here's my emerge -pqv 'sys-apps/systemd' (for systemd-201) [ebuild N ] sys-apps/systemd-201 USE="acl firmware-loader gudev introspection keymap kmod pam policykit tcpd -audit -cryptsetup -doc -gcrypt -http -lzma -openrc -python -qrcode (-selinux) -static-libs -vanilla -xattr" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" [uninstall ] sys-auth/nss-myhostname-0.3 [blocks b ] >=sys-apps/systemd-197 (">=sys-apps/systemd-197" is blocking sys-auth/nss-myhostname-0.3) [blocks b ] sys-auth/nss-myhostname ("sys-auth/nss-myhostname" is blocking sys-apps/systemd-201) [uninstall ] sys-fs/udev-204 USE="acl firmware-loader gudev hwdb introspection keymap kmod openrc -doc (-selinux) -static-libs" [blocks b ] sys-fs/udev ("sys-fs/udev" is blocking sys-apps/systemd-201) [uninstall ] app-admin/openrc-settingsd-1.0.1 USE="(-systemd)" [blocks b ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/udev-204, app-admin/openrc-settingsd-1.0.1)