Bug #68114 [Csd]: Build fails with gcc: Undefined symbols: ___extendsddf ___extendsfsd

Edit report at https://bugs.php.net/bug.php?id=68114&edit=1 ID: 68114 User updated by: php-bugs-2014 at ryandesign dot com Reported by: php-bugs-2014 at ryandesign dot com Summary: Build fails with gcc: Undefined symbols: ___extendsddf ___extendsfsd Status: Closed Type: Bug Package: MySQL related Operating System: OS X PHP Version: 5.5.17 Assigned To: mysql Block user comment: N Private report: N New Comment: Oh. On OS X 10.10, the test *is* failing, as it apparently should: checking whether whether compiler supports Decimal32/64/128 types... no Out of curiosity, on which systems or compilers is this support supposed to be available? Previous Comments: ------------------------------------------------------------------------ [2014-10-08 04:00:29] php-bugs-2014 at ryandesign dot com Thanks, but this is not fixing the problem for me. The configure script still detects that Decimal32/64/128 types are supported, and the build on OS X 10.6 and earlier still fails at the end with undefined symbols. The just released PHP 5.6.1 is also affected now, in addition to the previously affected 5.5.17 and 5.4.33. What's written in the commit message isn't right either. All parts of the configure and build should be using the same compiler; in MacPorts they certainly are, since we set the CC environment variable to point to the path to gcc 4.2.1. Additionally, cc may be a symlink to llvm-gcc-4.2 on Xcode 4, but it is not usual to use Xcode 4 on OS X 10.6 because obtaining it requires a paid Apple developer membership; the last free version of Xcode for OS X 10.6 is 3.2.6 in which gcc and cc are both the same gcc 4.2.1. The problem is also reproduced on OS X 10.4 using the MacPorts-provided version of Apple gcc 4.2.1. The MacPorts ticket links to a forum post ( https://forums.freebsd.org/viewtopic.php?f=5&t=48084 ) which claims that adding the include path to the mysqlnd extension directory to CFLAGS fixed the problem. That didn't work for me either. Note that this decimal-types configure test should possibly be failing on all versions of OS X. Here's what I see on OS X 10.10: $ clang test.c test.c:4:40: error: type of machine mode does not match type of base type typedef float dec32 __attribute__((mode(SD))); ^ test.c:4:40: error: unknown machine mode 'SD' 2 errors generated. $ clang --version Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix ------------------------------------------------------------------------ [2014-10-07 21:14:01] keyur@php.net The fix for this bug has been committed. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. See https://github.com/php/php-src/commit/648673bffe7a7c63ce6223fcbac7c118a114c893 ------------------------------------------------------------------------ [2014-10-01 13:38:37] keyur@php.net I will take a look at this today. ------------------------------------------------------------------------ [2014-10-01 12:39:26] johannes@php.net I can verify on this machine: $ uname -a Darwin foo 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:57:13 PST 2010; root:xnu-1504.3.12~1/RELEASE_X86_64 x86_64 $ gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Running configure I see checking whether whether compiler supports Decimal32/64/128 types... yes This is unexpected as manually trying the configure-test fails: $ cat test.c #include <stdio.h> int main(int argc, char **argv) { typedef float dec32 __attribute__((mode(SD))); dec32 k = 99.49f; double d2 = (double)k; return 0; } $ gcc test.c Undefined symbols: "___extendsddf", referenced from: _main in ccAnM5bQ.o ld: symbol(s) not found collect2: ld returned 1 exit status If I change the test in config9.m4 in another way that it should compile, but fail to link (add a line "does_not_exist();") the test fails as expected. Observation so far: The code fails when building stand-alone and when building as part of the PHP build, whoever it seems to work in configure's context. For a test I also changed from AC_TRY_RUN to AC_TRY_LINK. With AC_TRY_LINK this test fails on the Mac machine, but also on a Linux+gcc box where it used to work with AC_TRY_RUN. So I am confussed. ------------------------------------------------------------------------ [2014-09-30 10:32:58] mail_commercial at yahoo dot fr Hello, I'm the initiator of this request to the PHP maintainer in MacPorts. I've applied the workaround you've proposed. When removing the definition of HAVE_DECIMAL_FP_SUPPORT at the end of ext/mysqlnd/config9.m4 and cleaning the build terminates without any error. I'm reaching the limit of my skills. I don't know the use of the this constant. In my mind, even my 32 bits powerbook G4 has a decimal floating point support. my config : - hardware: mac G4, not intel - OS: mac os X leopard - compiler: gcc4.2 Hoping this information are useful. ------------------------------------------------------------------------ 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=68114 -- Edit this bug report at https://bugs.php.net/bug.php?id=68114&edit=1