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] ahar...@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] ahar...@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
