Opened 6 months ago

Closed 6 months ago

Last modified 6 months ago

#68710 closed defect (fixed)

py-matplotlib: automated build failures on High Sierra, Mojave, Catalina

Reported by: thomasrussellmurphy (Thomas Russell Murphy) Owned by: reneeotten (Renee Otten)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: py-matplotlib

Description

Current port health shows these three platforms failing from the last update: https://ports.macports.org/port/py39-matplotlib/details/

I'm also seeing a build failure locally on my 10.14.6 machine and can provide an additional log if desired.

Change History (4)

comment:1 Changed 6 months ago by reneeotten (Renee Otten)

Cc: reneeotten removed
Owner: set to reneeotten
Port: py-matplotlib added; py39-matplotlib removed
Status: newaccepted
Summary: py39-matplotlib: automated build failures on High Sierra, Mojave, Catalinapy-matplotlib: automated build failures on High Sierra, Mojave, Catalina

It looks like the problem is:

building 'matplotlib.backends._macosx' extension
creating build/temp.macosx-10.14-x86_64-cpython-39/matplotlib.backends._macosx
creating build/temp.macosx-10.14-x86_64-cpython-39/matplotlib.backends._macosx/src
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_python_py-matplotlib/py39-matplotlib/work/compwrap/cc/usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -I/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c src/_macosx.m -o build/temp.macosx-10.14-x86_64-cpython-39/matplotlib.backends._macosx/src/_macosx.o -Werror -fvisibility=hidden -flto
src/_macosx.m:48:49: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
static struct sigaction originalSigintAction = {0};
                                                ^
                                                {}
src/_macosx.m:61:42: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
        struct sigaction customAction = {0};
                                         ^
                                         {}
2 errors generated.

I cannot tell if this is really an error that should be fixed upstream (I kind of doubt it) or it's just something that some versions of Clang complain about... The latter case explains why it build on most systems, but not all.

I notice as well that the build is using -Werror as an flag/option, which is AFAIK not really we typically use in MacPorts. So I could/would look into where that is added in the build and just remove it or -perhaps better- replace it by -Wextra as is being done in some other ports.

I will take a look but cannot promise on when I'll get to it.

comment:2 Changed 6 months ago by thomasrussellmurphy (Thomas Russell Murphy)

Thanks for your attention. This is a blocker to upgrading/installing gnuradio on the affected OSs and other radio-encoding/decoding related ports that still default to python39 ports.

comment:3 Changed 6 months ago by reneeotten (Renee Otten)

Resolution: fixed
Status: acceptedclosed

In 6b60208ca52dc75b9c9ce8cd6bd85e9ccb689e02/macports-ports (master):

py-matplotlib: update to 3.8.2

  • disable use of -Werror

Closes: #68710

comment:4 in reply to:  1 Changed 6 months ago by jmroot (Joshua Root)

Replying to reneeotten:

I cannot tell if this is really an error that should be fixed upstream (I kind of doubt it) or it's just something that some versions of Clang complain about...

Doing what the warning suggests is a good idea for clarity, but like many other warnings, it's not something that will result in incorrect code behaviour. It would be nice to have an option to control the use of -Werror so upstream can keep using it when developing and in their CI builds, but leave it disabled by default for end user builds. If the idea hasn't already been brought up and rejected, it would be worth suggesting.

Note: See TracTickets for help on using tickets.