Edit report at https://bugs.php.net/bug.php?id=60328&edit=1

 ID:                 60328
 Updated by:         fel...@php.net
 Reported by:        a dot wehrmann at centersystems dot com
 Summary:            undefined reference to `__sync_fetch_and_add_4'
-Status:             Open
+Status:             Bogus
 Type:               Bug
 Package:            Compile Failure
 Operating System:   Linux
 PHP Version:        5.3.8
 Block user comment: N
 Private report:     N

 New Comment:

We already have fixed this issue properly in the SVN days ago, see bug #55874.
Now we check if the __sync_fetch_and_add_4 is available in the ./configure.

http://svn.php.net/viewvc/?view=revision&revision=319271

Thanks.


Previous Comments:
------------------------------------------------------------------------
[2011-11-18 12:53:03] a dot wehrmann at centersystems dot com

Description:
------------
I tried to cross-compile php-5.3.8 for a Coldfire/m68k V4e target and failed at 
the linking stage:

php_crypt_r.c:(.text+0x54): undefined reference to `__sync_fetch_and_add_4'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1

I'm using the Codesourcery toolchain
freescale-coldfire-m68k-linux-gnu-2011.03-98 with gcc-4.5.2.

Bug #55231 deals with the same
problem on HPUX. When I changed the following condition in php_crypt_r.c:99 from

#elif (defined(__GNUC__) && !defined(__hpux) && (__GNUC__ > 4 || \
    (__GNUC__ == 4 && (__GNUC_MINOR__ > 1 || (__GNUC_MINOR__ == 1 && 
__GNUC_PATCHLEVEL__ > 1)))))

to 

#elif (defined(__GNUC__) && !defined(__m68k__) && !defined(__hpux) && (__GNUC__ 
> 4 || \
    (__GNUC__ == 4 && (__GNUC_MINOR__ > 1 || (__GNUC_MINOR__ == 1 && 
__GNUC_PATCHLEVEL__ > 1)))))

everything works fine. You might be interested in the fact that I encountered 
the same problem using the boost C++ library on the same platform. They offer a 
macro "DISABLE_FENCED_BLOCKING" (or similar) that when defined prevents the 
usage of these gcc builtins, see:
http://lists.boost.org/boost-users/2010/09/62566.php

Maybe introducing a #define that allows for disabling the usage of these gcc 
builtins is a better solution than growing up that condition? Just a thought 
here...



------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60328&edit=1

Reply via email to