Bug #60925 [Opn]: fpm_atomic.h says unknown processor (m68k)

Edit report at https://bugs.php.net/bug.php?id=60925&edit=1 ID: 60925 User updated by: tg at debian dot org Reported by: tg at debian dot org Summary: fpm_atomic.h says unknown processor (m68k) Status: Open Type: Bug Package: FPM related Operating System: Linux PHP Version: 5.3.9 Block user comment: N Private report: N New Comment: OK; in the meantime I’ll try building without FPM, to see whether there are any other lurking issues on m68k. Thanks for the help with this. Previous Comments: ------------------------------------------------------------------------ [2012-01-31 00:50:00] aharvey@php.net Thanks again. It's been good to triage this down. :) I'll let Jérôme figure out what he wants to do here, since he's the FPM maintainer. I think your list of options pretty much covers it. ------------------------------------------------------------------------ [2012-01-31 00:39:53] tg at debian dot org Heh, your comment made me go and read the old changelogs of the Debian package on a guess, and I guessed right: php5 (5.3.5-1) unstable; urgency=low * Build the FPM SAPI (Closes: #603174) So this was simply never built before. Now there are two possibilities, disable FPM on m68k (unless gcc-4.7 or up is used) or ask the m68k porters for an implementation of the atomic things. I think. If you’ve got a better idea, do tell. By the way, there’s libatomic-ops-dev, which contains a number of atomic primitives and composed operations on a number of data types (but the catch is, you’ve got to use the data types of libatomic-ops-dev, not e.g. like mesa have a function atomic_dec which is passed an int32_t* so it’s not a plug-in replacement. That might be more interesting than hacking in m68k support now, and support for $next_arch later… m68k atomic operations apparently have another twist: the compare-and-swap operation only exists on some processors, and not in the Coldfire line, so the Linux kernel got a syscall now to ensure atomicity. GCC 4.7 uses the syscall; most “inlined” application code doesn’t… ------------------------------------------------------------------------ [2012-01-31 00:06:52] aharvey@php.net Ah, I didn't know that, so no, no need on the vanilla tarball front. Thanks! The fix here would be a patch for fpm_atomic.h implementing the same atomic functions for m68k as the other fallback platforms in there, such as x86 and SPARC v9. I'm not actually sure why 5.3.3-7 built at all, actually -- the only patch it had over stock 5.3.3 (which had no support at all for m68k) was implementing support for __sync_bool_compare_and_swap() if it existed, so it should have failed with the same #error. Interesting. ------------------------------------------------------------------------ [2012-01-30 16:52:13] tg at debian dot org configure:12302: checking if gcc supports __sync_bool_compare_and_swap configure:12319: m68k-linux-gnu-gcc -o conftest -O2 -Wall -fsigned-char -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -gstabs -fvisibility=hidden conftest.c -lrt >&5 /tmp/ccmCFUbp.o: In function `main': conftest.c:48: undefined reference to `__sync_bool_compare_and_swap_4' conftest.c:49: undefined reference to `__sync_add_and_fetch_4' collect2: ld returned 1 exit status configure:12319: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define __EXTENSIONS__ 1 | #define _ALL_SOURCE 1 | #define _GNU_SOURCE 1 | #define _POSIX_PTHREAD_SEMANTICS 1 | #define _TANDEM_SOURCE 1 | #define HAVE_DEV_URANDOM 1 | #define HAVE_SETENV 1 | #define HAVE_CLEARENV 1 | #define HAVE_ERRNO_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_STDIO_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_SYS_UIO_H 1 | #define HAVE_SYS_SELECT_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_ARPA_INET_H 1 | #define HAVE_NETINET_IN_H 1 | #define HAVE_PRCTL 1 | #define HAVE_CLOCK_GETTIME 1 | #define HAVE_PTRACE 1 | #define PROC_MEM_FILE "mem" | /* end confdefs.h. */ | | int | main () | { | | int variable = 1; | return (__sync_bool_compare_and_swap(&variable, 1, 2) | && __sync_add_and_fetch(&variable, 1)) ? 1 : 0; | | ; | return 0; | } configure:12329: result: no ------------------------------------------------------------------------ [2012-01-30 16:39:04] tg at debian dot org gcc version 4.6.2 (Debian 4.6.2-12) I know for sure it does NOT support __sync_* atomic builtins; on m68k, gcc-4.7 will introduce them, and a backport is not likely (I looked at it, but it depends on mach-indep changes that aren’t in 4.6 and I fear to break other things by that). Several other architectures also do not have support for them (but I can only sort-of speak for m68k at the moment). Do I still need to try building a vanilla tarball with this information? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60925 -- Edit this bug report at https://bugs.php.net/bug.php?id=60925&edit=1