Looks related to #67839, possibly HAVE_DECIMAL_FP_SUPPORT incorrectly being set under OSX in ext/mysqlnd/config9.m4

The missing symbols are from libdfp (decimal floating point)

I don't have OSX available to me right now, so it would be helpful if you could test this. You can simply delete the last few lines in config9.m4 to prevent the define being set.

If this turns out to be the case, hopefully someone with more OSX specific knowledge can fix the configure script.

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.

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.

I will take a look at this today.

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

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

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?

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

This ticket shows it is closed, but I am still having the same issue that ryandesign is having.

Hello,

I was reading with great interest the comment on this bug as of 8 October. I experienced the exact same issue while trying to compile php 5.6.1 with Apache 2.4.10.
The flags I used were:
LD_LIBRARY_PATH=/usr/X11R6/lib:/usr/local/lib:/Developer/SDKs/MacOSX10.6.sdk/usr/lib:/opt/gnome/lib:/usr/lib:/usr/local/pgsql/lib:/usr/local/BerkeleyDB/lib:/sw/lib
LDFLAGS=-L/usr/local/BerkeleyDB/lib -L/sw/lib
and the configure arguments were:
./configure --prefix=/usr/local/php --with-apxs2=/usr/local/apache2/bin/apxs --enable-mod-charset --with-config-file-path=/usr/local/php/etc --with-openssl --with-libxml-dir=/sw --with-pcre-regex=/usr/local/pcre --with-zlib=/usr --with-bz2 --enable-calendar --with-curl --enable-exif --with-gd --with-jpeg-dir=/sw --with-png-dir=/sw --with-xpm-dir=/usr/X11 --with-freetype-dir=/usr/X11 --with-t1lib=/sw --enable-gd-native-ttf --enable-gd-jis-conv --with-gettext --with-gmp=/sw --with-mhash --with-imap --with-kerberos --with-imap-ssl --with-ldap --enable-mbstring --with-mcrypt=/sw --with-mysql --with-pgsql --enable-cli --with-readline=/sw --enable-soap --enable-sockets --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-xsl --with-zlib --with-libexpat-dir=/usr --with-libxml-dir=/sw --with-xmlrpc --with-libzip=/sw --with-pear --enable-bcmath --enable-intl --with-icu-dir=/sw --with-iconv-dir=/usr

The error is:
Undefined symbols:
  "___extendsddf", referenced from:
      _ps_fetch_float in mysqlnd_ps_codec.o
  "___extendsfsd", referenced from:
      _ps_fetch_float in mysqlnd_ps_codec.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [libs/libphp5.bundle] Error 1

I am clueless as to how to solve this problem and would appreciate any assistance to help resolve this.

Regards,
Jacques

The problem seems to be that OS X does not support decimal floating point, but the configure script thinks it does. You could override the problematic test by appending

ac_cv_decimal_fp_supported=no

to your configure arguments. For example, run:

./configure ac_cv_decimal_fp_supported=no

However, I would like some assurance that it is indeed expected that OS X does not support decimal floating point regardless of OS X version or compiler, because that is what it seems like to me so far.

Thank you, the solution of using this argument worked.
I am just a bit puzzled that Mac would not recognise decimal floating point. Seems a bit weird.

Jacques

I've learned that clang does not support decimal floating point types at all:

http://clang.llvm.org/docs/UsersManual.html#gcc-extensions-not-implemented-yet

"clang does not support decimal floating point types (_Decimal32 and friends) or fixed-point types (_Fract and friends); nobody has expressed interest in these features yet, so it’s hard to say when they will be implemented."

And gcc only enables support for decimal floating point types by default on Linux, not OS X:

https://gcc.gnu.org/install/configure.html

"This is enabled by default only on PowerPC, i386, and x86_64 GNU/Linux systems. Other systems may also support it, but require the user to specifically enable it."

The Apple build of gcc 4.2.1 in Xcode doesn't use the --enable-decimal-float flag, according to "gcc -v", and neither do the newer gcc versions available in MacPorts. I don't know whether that's due to oversight or ignorance, or whether it was tried and found not to work.

But I think this answers my question: yes it is expected that decimal floating point is not available on OS X, so using ac_cv_decimal_fp_supported=no is a reasonable workaround for now.

As for fixing the configure script to detect this, perhaps "-O0" can be appended to the CFLAGS for the duration of this test.

Hello all,

Let me clarify a couple things. Decimal32/64 is not supported by Clang http://clang.llvm.org/docs/UsersManual.html#gcc-extensions-not-implemented-yet so OS X doesn't support it.

I am not sure what is up with the GCC. The version I used (i686-apple-darwin10-gcc-4.2.1) you can see it compiles but doesn't link.

The fix is not yet released. It is queued up for 5.5.19 (https://github.com/php/php-src/blob/PHP-5.5/NEWS) and 5.6.3 (https://github.com/php/php-src/blob/PHP-5.6/NEWS)

If it still doesn't resolve, please re-open this bug.

Ah I just repeated a bunch of what you said :) Should've read the full email thread before replying. 

I am marking the bug again as "Try a snapshot".

Please try using this snapshot:

  http://snaps.php.net/php-trunk-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I'd like to try the snapshot, but snaps.php.net has been down for days.

"This service is unavailable at the moment. Please try again in a day"

Please try using this snapshot:

  http://snaps.php.net/php5.5-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

5.5.19RC1 is released and available for download here http://server.famillecollet.com/php/ 

Release notes: https://github.com/php/php-src/blob/php-5.5.19RC1/NEWS

Thanks for making these snapshots available on a different server since snaps.php.net and qa.php.net are still down.

I tested 5.5.19RC1 and 5.6.3RC1, and there is no change in the issue.

Did you read all my previous messages in which I explained what the problem and solution are?

Yes I did read the comments and the patch I made specifically checks the compiled output to make sure it matches what's expected: https://github.com/php/php-src/commit/648673bffe7a7c63ce6223fcbac7c118a114c893

On Mac OS X 10.9 with gcc 4.2.1 from XCode I've had no issues compiling. And same with a gcc-4.9 from homebrew. I don't have access to OS X 10.6.

Can you pastebin or gist your config.log file with the failure? 

Also can you compile and run this snippet and paste the output?
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv) {
  typedef float dec32 __attribute__((mode(SD)));
  dec32 k = 99.49f;
  double d2 = (double)k;
  const char *check_str = "99.49";
  char print_str[32];
  snprintf(print_str, 32, "%f", d2);
  printf("Expected: %s, Actual: %s\n", check_str, print_str);
  return memcmp(print_str, check_str, 5);
}

You can revert that change; it doesn't help, as I said above on 2014-10-08. It is not possible that you tested that fix on Mac OS X 10.9 with gcc 4.2.1 from XCode because the versions of Xcode for Mac OS X 10.7 and later do not include any version of gcc. (Xcode 4 for those OS X versions include llvm-gcc42 which is different. Xcode 5 and later provide only clang.) The fix I propose is to modify the configure script so that "-O0" is added to the CFLAGS for this test, as apparently old gcc optimizes the test away somehow, as I said above on 2014-10-10.

Can you paste the config.log of a failed build for me to look at on pastebin?

I don't have a Mac OS box, so I'm having the commands run by a friend. Here's the config it works on: 
$ uname -a
Darwin 2414 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

I see it is Clang. If you're available on IRC somewhere, let me know. We can work through this faster.

Here is the config.log for php-5.6.3RC1 on OS X 10.6.8:

https://gist.github.com/ryandesign/4c4721cf740c014129e4

Here is the config.log after applying the patch I just attached, which fixes the problem as I suggested earlier:

https://gist.github.com/ryandesign/4b2d1a5e082f3cb90994

The config.log for the (default) -O2 case shows the test compiles *and* links *and* runs *and* exits with 0. So the same should happen for the main PHP executable...I don't understand why that linking fails.

I am a bit hesitant to change the optimizer level since that seems just paper over the bug in the compiler/linker. I'd rather add a check for 
#if defined(__APPLE__CC__) && __APPLE_CC__ > N

Can you tell me what the value of that macro is on your system?

My assumption is that the fact that the configure test compiles and links is an error. Disabling optimizations for the duration of the configure test works around that error and allows the configure test to properly detect the absence of decimal fp support. Yes, this is papering over a bug in the compiler and/or linker but that's the best we can hope for since Apple is not going to be releasing any updated versions of the developer tools for the affected OS X versions because they are several major versions old by now.

Inspecting the value of __APPLE_CC__ doesn't seem likely to help identify the broken compilers in this situation. With an affected version of gcc from OS X 10.6 ("gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)"), the value of __APPLE_CC__ is "5666". However that OS X version also includes the llvm-gcc compiler ("gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)") which is not affected by the problem and its __APPLE_CC__ value is "5658". An early version of clang is also included ("Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)"); it is not affected by the bug and its __APPLE_CC__ value is "5621". The version of gcc-4.2 on OS X 10.5 ("gcc version 4.2.1 (Apple Inc. build 5577)") is affected; its __APPLE_CC__ value is 5577.

It doesn't seem necessary to identify the affected compilers in any way; just disable optimizations for this configure test. This should not have any adverse effects on the test's ability to detect the feature on other platforms nor would it have any effect on the final executable's performance.

You previously asked me to compile and run a snippet. Here's the result on OS X 10.5:

$ gcc-4.2 snippet.c
Undefined symbols:
  "___extendsddf", referenced from:
      _main in ccODpbxz.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
$ gcc-4.2 -O1 snippet.c
$ ./a.out 
Expected: 99.49, Actual: 99.490000
$ echo $?
0
$

One last request: could you put the -O1 binary somewhere I could download from?

Certainly; here is the compiled program:

http://ryandesign.com/tmp/php-bug-68114/snippet

Hello,

I am trying to compile 5.6.3 on FreeBSD and get the following.. I applied the attached patch and still get the same error... any advice?

/home/b/php-5.6.3/ext/mysqlnd/mysqlnd_ps_codec.c:233: undefined reference to `__extendsfsd'
/home/b/php-5.6.3/ext/mysqlnd/mysqlnd_ps_codec.c:233: undefined reference to `__extendsddf'

Thanks!

@cbrugh, a workaround you can use immediately is described in my comment above from 2014-10-09 09:04 UTC. The fix I propose is described in my comment above from 2014-11-03 21:37 UTC.

(Re: https://bugs.php.net/bug.php?id=68192#1412808117)

https://bugs.php.net/bug.php?id=68114#1412845446 solution worked for me.

It's not just OS X !

At least OpenBSD and FreeBSD all have the same (or highly similar) problem in 5.5.20 and 5.6.4

The workaround of adding "ac_cv_decimal_fp_supported=no" to the configure options seems to get through the compile phase on 5.6.4 on OpenBSD already.

The snippet on OpenBSD:

$ gcc -o t t.c
/tmp//ccaYXIKe.o(.text+0x29): In function `main':
: undefined reference to `__extendsddf'
collect2: ld returned 1 exit status
$ gcc -O2 -o t t.c
$ ./t   
Expected: 99.49, Actual: 99.490000

Suggest to either make sure the optimizer doesn't optimize the test program or remove the optimizer in options during the configure as it's too smart to execute the test. [I'm not that familiar with the PHP build system]

FWIW: it's an old OpenBSD version I'm running - I know ...
gcc version 4.2.1 20070719

A patch is coming in the next few days to fix this by making the Decimal point support opt-in and defaulting to the float-to-string-to-double method.

Pull request https://github.com/php/php-src/pull/983 is up and completely removes decimal point support. 

I will merge it into the repository in a few days once folks have had a chance to review it.

Thank you very much the bug reports and being patient!

Please try using this snapshot:

  http://snaps.php.net/php5.5-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

snaps.php.net seems to be permanently dead. Please try 5.5 directly from the git repo (Instructions: http://php.net/git.php)

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

Please re-open. The problem remains with 5.4.38.

Unfortunately 5.4 stopped accepting bug fixes for non-security issues a while back so I can no longer port the patch over.