Opened 4 years ago

Closed 4 years ago

#60548 closed defect (fixed)

py-scipy: error: call to 'fmaf' is ambiguous

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: py-scipy

Description

py-scipy fails to build. I see a few instances of this in the log:

error: invalid value 'c++14' in '-std=c++14'

The portfile already says:

        # require C++11 as of 1.4.0; use C11 as well to match
        compiler.c_standard 2011
        compiler.cxx_standard 2011

If it now requires C++14 then I guess it needs to be changed to:

        PortGroup compiler_blacklist_versions 1.0

        compiler.c_standard 2011
        compiler.cxx_standard 2014
        # Remove this once base's compiler selection for C++14 is fixed:
        # https://github.com/macports/macports-base/pull/162
        compiler.blacklist-append {clang < 602}

If on the other hand it's just checking whether the compiler supports C++14 and will fall back to C++11, then the real errors may instead be:

In file included from scipy/fft/_pocketfft/pypocketfft.cxx:19:
scipy/fft/_pocketfft/pocketfft_hdronly.h:304:7: error: call to 'fmaf' is ambiguous
  r = fmaf (r, s, -1.335021972656250000e+00f);
      ^~~~
/usr/include/math.h:553:14: note: candidate function
extern float fmaf(float, float, float);
             ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:1211:40: note: candidate function
inline _LIBCPP_INLINE_VISIBILITY float fmaf(float __x, float __y, float __z) _NOEXCEPT {return (float)((double)__x*__y + __z);}
                                       ^
In file included from scipy/fft/_pocketfft/pypocketfft.cxx:19:
scipy/fft/_pocketfft/pocketfft_hdronly.h:305:7: error: call to 'fmaf' is ambiguous
  r = fmaf (r, s,  4.058703899383544922e+00f);
      ^~~~
/usr/include/math.h:553:14: note: candidate function
extern float fmaf(float, float, float);
             ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:1211:40: note: candidate function
inline _LIBCPP_INLINE_VISIBILITY float fmaf(float __x, float __y, float __z) _NOEXCEPT {return (float)((double)__x*__y + __z);}
                                       ^
In file included from scipy/fft/_pocketfft/pypocketfft.cxx:19:
scipy/fft/_pocketfft/pocketfft_hdronly.h:306:7: error: call to 'fmaf' is ambiguous
  r = fmaf (r, s, -4.934802055358886719e+00f);
      ^~~~
/usr/include/math.h:553:14: note: candidate function
extern float fmaf(float, float, float);
             ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:1211:40: note: candidate function
inline _LIBCPP_INLINE_VISIBILITY float fmaf(float __x, float __y, float __z) _NOEXCEPT {return (float)((double)__x*__y + __z);}
                                       ^
In file included from scipy/fft/_pocketfft/pypocketfft.cxx:19:
scipy/fft/_pocketfft/pocketfft_hdronly.h:732:1: error: thread-local storage is unsupported for the current target
thread_local size_t thread_id = 0;
^
scipy/fft/_pocketfft/pocketfft_hdronly.h:733:1: error: thread-local storage is unsupported for the current target
thread_local size_t num_threads = 1;
^

If so, I don't know what the fix for those is.

Change History (5)

comment:1 Changed 4 years ago by michaelld (Michael Dickens)

Hmmm ... the SciPy source shows that someone added in the C++14 code, then it was removed. The comments indicate that it should be buildable using C++14, but only C++11 is required; that there are no C++14 specific features. So .... not sure why C++14 is showing up in the actual build! Let me try switching the required compiler to C++14 and see if that works on modern macOS.

comment:2 Changed 4 years ago by reneeotten (Renee Otten)

isn't the problem here error: thread-local storage is unsupported for the current target? I see that the Portfile uses compiler.thread_local_storage yes but we also know that this currently is not sufficient to select a proper compiler. I think Marcus has made the changes in base already to make sure that this will work correctly in the future, but for now manual blacklisting of compiler is still required. Admittedly I couldn't figure out which compiler is present in Xcode 6.2, but if it's below version 8 it will not work. I am sorry if I'm saying obvious things here and you already considered this...

See the discussion listed below:

# build fails with "error: thread-local storage is not supported for the current target"
# setting "compiler.thread_local_storage yes" does not work, so for now just use blacklisting
# See: https://lists.macports.org/pipermail/macports-dev/2019-November/041503.html
compiler.blacklist-append {clang < 800}
Last edited 4 years ago by reneeotten (Renee Otten) (previous) (diff)

comment:3 Changed 4 years ago by michaelld (Michael Dickens)

I hadn't noticed that; thanks! I'm working on updated my OSX 10.9 build computer. Once that's done I'll test out both of these and see if one works.

comment:4 in reply to:  2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to reneeotten:

Admittedly I couldn't figure out which compiler is present in Xcode 6.2

See XcodeVersionInfo.

We also list the Xcode and compiler versions installed on the buildbot workers, for example https://build.macports.org/buildslaves/ports-10.9_x86_64

comment:5 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

In c8ee1c4af31ba4bfde234104e7a11cfea2bbf930/macports-ports (master):

py-scipy: Blacklist clang < 800

Closes: #60548
Closes: #60633

Note: See TracTickets for help on using tickets.