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: I've at least figured out what the difference is between compiling the test script on the command line and having the configure script compile it: the configure script uses the CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS and LIBS it's given, which in MacPorts' case includes optimization flags. When using any optimization level above 0, the test script (either the old version or the new version) compiles with no error: $ gcc-apple-4.2 test.c -o test -O0; echo $? Undefined symbols: "___extendsddf", referenced from: _main in cc22Pp30.o ld: symbol(s) not found collect2: ld returned 1 exit status 1 $ gcc-apple-4.2 test.c -o test -O1; echo $? 0 Previous Comments: ------------------------------------------------------------------------ [2014-10-08 04:02:12] php-bugs-2014 at ryandesign dot com 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? ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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