udev-212 fails to link on Sparc v8 This is a bug only on Sparc v8 not v8+ or v9. Probably also a bug on v7. Reproducible: Always Steps to Reproduce: 1. emerge -1 =sys-fs/udev on a sparc v8 system If you need access to a Sun machine contact me or p13 to run tests if you don't have a Sun machine let me know... I'll be on IRC at #gentoo-sparc. To use p13's machine you'll need to grab a stage from here from here: http://gh0stwriter.net/gentoo/ I will be uploading stage1 and stage3 tarballs next week hopefully. at http://gh0stwriter.net/gentoo/ Actual Results: udev-212 fails to link and emerge Expected Results: udev-212 should link and emerge
Created attachment 379318 [details] sucessfull udev 208 build log
Created attachment 379320 [details] udev-212-build.log.gz The log was too large to attach unziped
leafblower temp # emerge --info Portage 2.2.8-r1 (default/linux/sparc/13.0, gcc-4.7.3, glibc-2.17, 3.9.11-gentoo-r1 sparc64) ================================================================= System uname: Linux-3.9.11-gentoo-r1-sparc64-sun4v-with-gentoo-2.2 KiB Mem: 16497936 total, 2599936 free KiB Swap: 48184 total, 48184 free Timestamp of tree: Thu, 19 Jun 2014 14:30:01 +0000 ld GNU ld (Gentoo 2.23.2 p1.0) 2.23.2 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5-r3, 3.3.3 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.13.4 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.7.3-r1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.13 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo ACCEPT_KEYWORDS="sparc" ACCEPT_LICENSE="* -@EULA" CBUILD="sparc-unknown-linux-gnu" CFLAGS="-O2 -pipe -mcpu=v8" CHOST="sparc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -mcpu=v8" DISTDIR="/usr/portage/distfiles" FCFLAGS="" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news nodoc noinfo noman parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j32" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-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="" USE="acl berkdb bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 modules ncurses nls nptl openmp pam pcre readline session sparc ssl tcpd unicode zlib" 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 ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="dummy fbdev sunbw2 suncg14 suncg3 suncg6 sunffb sunleo v4l" 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, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON Also my make.defaults # Copyright 1999-2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/profiles/default-linux/sparc/sparc32/make.defaults,v 1.18 2007/06/27 17:27:31 gustavoz Exp $ ARCH="sparc" ACCEPT_KEYWORDS="${ARCH}" FEATURES="sandbox sfperms" # 32bit kernel, 32bit userland CHOST="sparc-unknown-linux-gnu" PROFILE_ARCH="sparc" # Just sparc32 binutils for linux-headers CTARGETS_BINUTILS="sparc-unknown-linux-gnu" # Multilib stuff MULTILIB_ABIS="sparc32" DEFAULT_ABI="sparc32" ABI=${DEFAULT_ABI} CFLAGS_sparc32="-m32" LDFLAGS_sparc32="-m elf32_sparc" CHOST_sparc32="sparc-unknown-linux-gnu" CTARGET_sparc32="sparc-unknown-linux-gnu" CDEFINE_sparc32="!__arch64__" LIBDIR_sparc32="lib" # Compiler flags CFLAGS="-O2 -pipe" CXXFLAGS=${CFLAGS} # 2006/10/05 - Gustavo Zacarias <gustavoz@gentoo.org> # Defaults for video drivers VIDEO_CARDS="dummy fbdev sunbw2 suncg14 suncg3 suncg6 sunffb sunleo"
If I understood correctly, this is because of missing atomic ops in the compiler for -mcpu=v8, so the bug is in the toolchain, reassining the bug accordingly
Created attachment 379322 [details, diff] udev-214.ebuild.patch I'd like to know if something like this would workaround the problem, and still give an usable udevd?
Comment on attachment 379322 [details, diff] udev-214.ebuild.patch With the patch: libtool: link: sparc-unknown-linux-gnu-gcc -std=gnu99 -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 -Wsuggest-attribute=noreturn -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 -fPIE --param=ssp-buffer-size=4 -ffat-lto-objects -O2 -pipe -Wl,--no-undefined -Wl,--gc-sections -Wl,-z -Wl,relro -Wl,-z -Wl,now -pie -Wl,-O1 -o udevadm src/udev/udevadm.o src/udev/udevadm-info.o src/udev/udevadm-control.o src/udev/udevadm-monitor.o src/udev/udevadm-hwdb.o src/udev/udevadm-settle.o src/udev/udevadm-trigger.o src/udev/udevadm-test.o src/udev/udevadm-test-builtin.o -Wl,--as-needed ./.libs/libudev-core.a -lrt -lblkid -lkmod -lacl -ldl -pthread ./.libs/libudev-core.a(libsystemd_internal_la-sd-rtnl.o): In function `sd_rtnl_unref': sd-rtnl.c:(.text.sd_rtnl_unref+0x30): undefined reference to `__sync_sub_and_fetch_4' ./.libs/libudev-core.a(lt21-libsystemd_internal_la-rtnl-message.o): In function `sd_rtnl_message_ref': rtnl-message.c:(.text.sd_rtnl_message_ref+0x1c): undefined reference to `__sync_add_and_fetch_4' ./.libs/libudev-core.a(lt21-libsystemd_internal_la-rtnl-message.o): In function `sd_rtnl_message_unref': rtnl-message.c:(.text.sd_rtnl_message_unref+0x10): undefined reference to `__sync_sub_and_fetch_4' collect2: error: ld returned 1 exit status
(In reply to Samuli Suominen from comment #6) > Comment on attachment 379322 [details, diff] [details, diff] > udev-214.ebuild.patch > > With the patch: > > libtool: link: sparc-unknown-linux-gnu-gcc -std=gnu99 -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 > -Wsuggest-attribute=noreturn -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 -fPIE --param=ssp-buffer-size=4 -ffat-lto-objects -O2 > -pipe -Wl,--no-undefined -Wl,--gc-sections -Wl,-z -Wl,relro -Wl,-z -Wl,now > -pie -Wl,-O1 -o udevadm src/udev/udevadm.o src/udev/udevadm-info.o > src/udev/udevadm-control.o src/udev/udevadm-monitor.o > src/udev/udevadm-hwdb.o src/udev/udevadm-settle.o src/udev/udevadm-trigger.o > src/udev/udevadm-test.o src/udev/udevadm-test-builtin.o -Wl,--as-needed > ./.libs/libudev-core.a -lrt -lblkid -lkmod -lacl -ldl -pthread > ./.libs/libudev-core.a(libsystemd_internal_la-sd-rtnl.o): In function > `sd_rtnl_unref': > sd-rtnl.c:(.text.sd_rtnl_unref+0x30): undefined reference to > `__sync_sub_and_fetch_4' > ./.libs/libudev-core.a(lt21-libsystemd_internal_la-rtnl-message.o): In > function `sd_rtnl_message_ref': > rtnl-message.c:(.text.sd_rtnl_message_ref+0x1c): undefined reference to > `__sync_add_and_fetch_4' > ./.libs/libudev-core.a(lt21-libsystemd_internal_la-rtnl-message.o): In > function `sd_rtnl_message_unref': > rtnl-message.c:(.text.sd_rtnl_message_unref+0x10): undefined reference to > `__sync_sub_and_fetch_4' > collect2: error: ld returned 1 exit status While I'm not sure because I can't test, this bug can be avoided with eudev because we done have sd_rtnl_message_unref() or any of the sd_* functions. I understand this is just a workaround to a problem in some sparc atomics so if it does work, its just a workaround and not a fix.
(In reply to Anthony Basile from comment #7) n > because we done have sd_rtnl_message_unref() or any of the sd_* functions. That should read "because we don't have ..."
(In reply to Samuli Suominen from comment #4) i don't think there's any bug here in the toolchain. afaik, there is no guarantee that certain builtins will exist like sync_sub_and_fetch. you can add configure time checks for their existence (make sure you link the code as some targets will expand into a libgcc call).
Mike, OK. Chase, can you report this to the systemd-devel mailing list[1]? I'm afraid they'll just point out this is a toolchain problem, but lets at least try [1] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I have just spent a while researching this and unfortunately this bug is going to be impossible to fix, you cannot build more recent versions of udev on a v8 which lacks the backing hardware intrinsics. This is because there is no software implementation of these calls for sparc (neither 64-bit nor 32-bit, but the former is irrelevant since all 64-bit subarches support. Here is the detailed explanation. Buildroot uses the BR2_TOOLCHAIN_HAS_SYNC_4 requirement to indicate whether a particular arch supports the __sync_val_compare_and_swap_4 intrinsic. However you can see here that they explicitly specify that this requirement is not met for 32-bit sparc: https://github.com/buildroot/buildroot/blob/master/toolchain/Config.in#L751 I tracked this down to the following commit which has a much better explanation: https://github.com/buildroot/buildroot/commit/6856e417da4f3aa77e2a814db2a89429af072f7d The relevant snippets: (1) The __sync_*() family of functions, which have been in gcc for a long time (probably gcc 4.1). They are available in variants operating on 1-byte, 2-byte, 4-byte and 8-byte integers. Some architectures implement a number of variants, some do not implement any, some implement all of them. They are now considered "legacy" by the gcc developers but are nonetheless still being used by a significant number of userspace libraries and applications. https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html For (1), a single BR2_ARCH_HAS_ATOMICS is not sufficient, because depending on the architecture, some variants may or may not be available. Setting BR2_ARCH_HAS_ATOMICS to false as soon as one of the variant is missing would cause a large number of packages to become unavailable, even if they in fact use only more common variants available on a large number of architectures. For this reason, we've chosen to introduce four new Config.in options: - BR2_TOOLCHAIN_HAS_SYNC_1 - BR2_TOOLCHAIN_HAS_SYNC_2 - BR2_TOOLCHAIN_HAS_SYNC_3 - BR2_TOOLCHAIN_HAS_SYNC_4 Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte and 8-byte __sync_*() built-ins respectively. This generated the following table indicating support: __sync __atomic gcc 1 2 4 8 1 2 4 8 ARC Y Y Y - Y Y Y L 4.8 [with BR2_ARC_ATOMIC_EXT] ARC - - - - L L L L 4.8 [without BR2_ARC_ATOMIC_EXT] ARM Y Y Y X Y Y Y Y 4.8, 4.7 ARM Y Y Y - 4.5 AArch64 Y Y Y Y Y Y Y Y 4.9, 5.1 Bfin - - Y - 4.3 i386 (i386) - - - - L L L L 4.9 i386 (i486..) Y Y Y - L L L L 4.9 [i486, c3, winchip2, winchip-c6] i386 (> i586) Y Y Y Y L L L L 4.9 Microblaze - - Y - L L Y L 4.9 MIPS Y Y Y - Y Y Y L 4.9 MIPS64 Y Y Y Y Y Y Y Y 4.9 NIOS 2 Y Y Y - Y Y Y L 4.9, 5.2 PowerPC Y Y Y - Y Y Y L 4.9 SuperH Y Y Y - Y Y Y L 4.9 SPARC - - - - L L L L 4.9 SPARC64 Y Y Y Y Y Y Y Y 4.9 x86_64 Y Y Y Y Y Y Y Y 4.7, 4.9 Xtensa Y Y Y - Y Y Y Y 4.9 As you can see, 32-bit sparc has no support for any of the sync intrinsics. Now the only remaining question was, why does this work on v8+ and v9 even with a 32-bit toolchain? For that I tracked down the gcc machine description. I found somebody who had the identical problem here: https://stackoverflow.com/questions/9329020/undefined-reference-to-sync-val-compare-and-swap-4-error-at-compilation-usi And the instructions specified to link libgcc_s, not libatomic. It turns out that the software implementations for these intrinsics are in libgcc/config/*/linux-atomic*.c for the respective architectures. But there is no such file for sparc. So I went to the global machine description for sparc and all the way at the bottom, it includes "sync.md": https://github.com/gcc-mirror/gcc/blob/master/gcc/config/sparc/sparc.md#L9532 And inside there we finally find the explanation of what gcc subarches support this in hardware: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/sparc/sync.md#L175 (define_expand "atomic_compare_and_swap<mode>" [(match_operand:SI 0 "register_operand" "") ;; bool output (match_operand:I 1 "register_operand" "") ;; val output (match_operand:I 2 "mem_noofs_operand" "") ;; memory (match_operand:I 3 "register_operand" "") ;; expected (match_operand:I 4 "register_operand" "") ;; desired (match_operand:SI 5 "const_int_operand" "") ;; is_weak (match_operand:SI 6 "const_int_operand" "") ;; mod_s (match_operand:SI 7 "const_int_operand" "")] ;; mod_f "(TARGET_V9 || TARGET_LEON3) && (<MODE>mode != DImode || TARGET_ARCH64 || TARGET_V8PLUS)" { sparc_expand_compare_and_swap (operands); DONE; }) Thus you need a V9, a LEON3, or a V8PLUS (with a 64-bit toolchain OR with DImode disabled, unsure what that is). sparc_expand_compare_and_swap is where the actual translation to the assembly implementation is. So there you have it, unfortunately we can't fix this unless you would like to contribute a software implementation of these sync intrinsics to gcc. I'll leave this open for a couple days before closing in case anyone from toolchain would like to comment on it.
@matoro "this bug is going to be impossible to fix" ...if you are going to sell yourself that short then you may as well start looking for a different line of work with that mentality heh. I got in quite a lot of trouble as a kid for saying similar things. It's kind of shame this bug has been open so long, Implementations of sync and atomic do exist however they are slow so nobody ever bothered to actually include them. It would be nice if this just worked even if it was slow though. Its been a few years but I think boehm-gc actually already has or had implementations that were functional on Sparc v7/v8 but slow if you want to find some existing code that should work. You might have to go back to an older version of it say around 2015 or so to get the correct code. Also reported this to systemd years ago and they wont-fixed it faster than you could blink... not sure if the culture over there has improved in recent years at all.
FWIW he's filed https://github.com/systemd/systemd/pull/23963 upstream which should help a bit.
(In reply to Chase Rayfield from comment #12) > @matoro "this bug is going to be impossible to fix" ...if you are going to > sell yourself that short then you may as well start looking for a different > line of work with that mentality heh. I got in quite a lot of trouble as a > kid for saying similar things. > > It's kind of shame this bug has been open so long, Implementations of sync > and atomic do exist however they are slow so nobody ever bothered to > actually include them. It would be nice if this just worked even if it was > slow though. Its been a few years but I think boehm-gc actually already has > or had implementations that were functional on Sparc v7/v8 but slow if you > want to find some existing code that should work. You might have to go back > to an older version of it say around 2015 or so to get the correct code. > > Also reported this to systemd years ago and they wont-fixed it faster than > you could blink... not sure if the culture over there has improved in recent > years at all. Yes, I spoke far too soon on this one - my apologies. What I should have specified is that this is not possible to fix without a code change in systemd as they are relying on the __sync intrinsics. After doing some further research I found that all __sync intrinsics can be expressed in terms of __atomic intrinsics (though not without some ugliness) and so I have filed an upstream PR at https://github.com/systemd/systemd/pull/23963 However I do think that it would be a poor idea to maintain this as a downstream patch, would rather wait for a new systemd release once it gets merged.
My systemd PR has been merged, but this is now going to depend on meson respecting the LIBS environment variable from the autoconf specification. I've opened an issue for this at https://github.com/mesonbuild/meson/issues/10621, but they don't seem particularly inclined to prioritize this, so I will have to investigate implementing it myself.
Just checking: is this still an issue with current versions of systemd?
(In reply to Mike Gilbert from comment #16) > Just checking: is this still an issue with current versions of systemd? My systemd PR has been merged, but we don't have any way to effect the change by adding in -latomic, because meson does not respect LIBS. If you throw it in with append-ldflags in the ebuild, you get a QA warning.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=82a0082762f7687ec3750a398f4e35af55ed8714 commit 82a0082762f7687ec3750a398f4e35af55ed8714 Author: Jakov Smolić <jsmolic@gentoo.org> AuthorDate: 2023-09-23 00:51:19 +0000 Commit: Jakov Smolić <jsmolic@gentoo.org> CommitDate: 2023-09-23 00:51:28 +0000 sys-fs/udev: treeclean Closes: https://bugs.gentoo.org/514016 Closes: https://bugs.gentoo.org/804218 Closes: https://bugs.gentoo.org/701056 Signed-off-by: Jakov Smolić <jsmolic@gentoo.org> profiles/package.mask | 1 - profiles/targets/systemd/package.mask | 3 +-- sys-fs/udev/metadata.xml | 11 ----------- sys-fs/udev/udev-250.ebuild | 15 --------------- 4 files changed, 1 insertion(+), 29 deletions(-)
