py38-kiwisolver @1.3.1 does not build on PPC Leopard, Mac OS X 10.5.8, because of unrecognized command line option '-stdlib=libc++'

[ballapete (Peter "Pete" Dyballa)]

DEBUG: system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_python_py-kiwisolver/py38-kiwisolver/work/kiwi-1.3.1" && /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 setup.py --no-user-cfg build -j1 
running build
running build_ext
building 'kiwisolver' extension
creating build
creating build/temp.macosx-10.5-ppc-3.8
creating build/temp.macosx-10.5-ppc-3.8/py
/opt/local/bin/gcc-mp-7 -fno-strict-aliasing -Wsign-compare -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -pipe -Os -arch ppc -isysroot/ -I/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/cppy/include -I. -I/opt/local/Library/Frameworks/Python.framework/Versions/3.8/include/python3.8 -c py/kiwisolver.cpp -o build/temp.macosx-10.5-ppc-3.8/py/kiwisolver.o -std=c++11 -stdlib=libc++
gcc-mp-7: error: unrecognized command line option '-stdlib=libc++'
error: command '/opt/local/bin/gcc-mp-7' failed with exit status 1
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_python_py-kiwisolver/py38-kiwisolver/work/kiwi-1.3.1" && /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 setup.py --no-user-cfg build -j1 
Exit code: 1
Error: Failed to build py38-kiwisolver: command execution failed

[ballapete (Peter "Pete" Dyballa)]

Main.log from PPC Leopard

[reneeotten (Renee Otten)]

it ​appears that py38-kiwisolver builds properly all the way down to 10.6.

The port requests compiler.cxx_standard 2011 so presumably an appropriate compiler should be selected. I don't know why gcc-mp-7 does not understand the -stdlib=libc++ flag. Did the previous version (v.1.2.0) work correctly? I don't really see relevant changes in the latest update, so I am not sure if it's related to this specific port or if something has changed in another port or MacPorts base (e.g., the compiler selection).

Finally, I have no access to a 10.5 system, nor the expertise or interest really to track this down. Of course if you or someone else (likely Ken will have a good idea! I'll CC him on the ticket) wants to try and fix this, please do and submit a PR.

[kencu (Ken)]

The most likely explanation is that the software itself is (helpfully!) putting the -stdlib=libc++ onto the build somewhere, I would think, as MacPorts should not be doing it anywhere.

Yep, right here <​https://github.com/nucleic/kiwi/blob/7c4e9760d424e66c857e101c3171b545aef23050/setup.py#L58>.

we just have to patch that out, and let macports' defaults take care of things, I think.

[ballapete (Peter "Pete" Dyballa)]

The port requests compiler.cxx_standard 2011 so presumably an appropriate compiler should be selected. I don't know why gcc-mp-7 does not understand the -stdlib=libc++ flag.

Isn't this a g++ switch? But gcc is compiling…

Did the previous version (v.1.2.0) work correctly?

I don't know. I did not try before to get rid of Python 2.7. So this dependency hit me for the first time – and all need is py38-nltk (which can be installed with pip3 without any dependency).

[kencu (Ken)]

For interest, gcc has learned to accept the -stdlib=libc++ flag in the main Darwin gcc developer's repos, and that ability will be moved into gcc mainline and backported to gcc7 in the near future.

Now that will cause some other problems -- cross-standard-library issues, etc -- but at least we have a powerful new feature we'll be able to make use of.

[ballapete (Peter "Pete" Dyballa)]

I think line #59

                ext.extra_link_args += ['-stdlib=libc++']

must be removed as well (so that line #57 can be deleted too), because now this happens:

/opt/local/bin/gcc-mp-7 -fno-strict-aliasing -Wsign-compare -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -pipe -Os -arch ppc -isysroot/ -I/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/cppy/include -I. -I/opt/local/Library/Frameworks/Python.framework/Versions/3.8/include/python3.8 -c py/variable.cpp -o build/temp.macosx-10.5-ppc-3.8/py/variable.o -std=c++11
creating build/lib.macosx-10.5-ppc-3.8
/opt/local/bin/g++-mp-7 -bundle -undefined dynamic_lookup -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -arch ppc -isysroot/ build/temp.macosx-10.5-ppc-3.8/py/kiwisolver.o build/temp.macosx-10.5-ppc-3.8/py/constraint.o build/temp.macosx-10.5-ppc-3.8/py/expression.o build/temp.macosx-10.5-ppc-3.8/py/solver.o build/temp.macosx-10.5-ppc-3.8/py/strength.o build/temp.macosx-10.5-ppc-3.8/py/term.o build/temp.macosx-10.5-ppc-3.8/py/variable.o -o build/lib.macosx-10.5-ppc-3.8/kiwisolver.cpython-38-darwin.so -stdlib=libc++
g++-mp-7: error: unrecognized command line option '-stdlib=libc++'
error: command '/opt/local/bin/g++-mp-7' failed with exit status 1
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_python_py-kiwisolver/py38-kiwisolver/work/kiwi-1.3.1" && /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 setup.py --no-user-cfg build -j1 

[ballapete (Peter "Pete" Dyballa)]

It built:

/opt/local/bin/g++-mp-7 -bundle -undefined dynamic_lookup -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -arch ppc -isysroot/ build/temp.macosx-10.5-ppc-3.8/py/kiwisolver.o build/temp.macosx-10.5-ppc-3.8/py/constraint.o build/temp.macosx-10.5-ppc-3.8/py/expression.o build/temp.macosx-10.5-ppc-3.8/py/solver.o build/temp.macosx-10.5-ppc-3.8/py/strength.o build/temp.macosx-10.5-ppc-3.8/py/term.o build/temp.macosx-10.5-ppc-3.8/py/variable.o -o build/lib.macosx-10.5-ppc-3.8/kiwisolver.cpython-38-darwin.so
ld: warning: direct access in kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) to global weak symbol kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) means the weak symbol cannot be overriden at runtime. This was likely caused by different translation units being compiled with different visiblity settings.
ld: warning: direct access in kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) to global weak symbol kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) means the weak symbol cannot be overriden at runtime. This was likely caused by different translation units being compiled with different visiblity settings.
ld: warning: direct access in kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) to global weak symbol kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) means the weak symbol cannot be overriden at runtime. This was likely caused by different translation units being compiled with different visiblity settings.
ld: warning: direct access in kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) to global weak symbol kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) means the weak symbol cannot be overriden at runtime. This was likely caused by different translation units being compiled with different visiblity settings.
ld: warning: direct access in kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) to global weak symbol kiwi::impl::DebugHelper::dump(kiwi::impl::Symbol const&, std::basic_ostream<char, std::char_traits<char> >&) means the weak symbol cannot be overriden at runtime. This was likely caused by different translation units being compiled with different visiblity settings.

[reneeotten (Renee Otten)]

Replying to ballapete:

The port requests compiler.cxx_standard 2011 so presumably an appropriate compiler should be selected. I don't know why gcc-mp-7 does not understand the -stdlib=libc++ flag.

Isn't this a g++ switch? But gcc is compiling…

Did the previous version (v.1.2.0) work correctly?

I don't know. I did not try before to get rid of Python 2.7. So this dependency hit me for the first time – and all need is py38-nltk (which can be installed with pip3 without any dependency).

okay, so py38-kiwisolver is being pulled in by py38-matplotlib which is listed under extra_requires in setup.py. So if you don't need the plotting, then the quickest solution is for now to just remove the {matplotlib} dependency from {py-nltk} and it will likely install without issues.

To do so (of course that change will be gone after a selfupdate), type: sudo vi `port file py-nltk`, remove the dependency, and try to install again.

[ballapete (Peter "Pete" Dyballa)]

Patch to remove the faulty darwin case in setup.py

[reneeotten (Renee Otten)]

did you verify that this doesn't cause any trouble on other OSes than 10.5 and/or when compiling with clang?

[edit: sorry I didn't read Ken's comment carefully enough - this seems the correct solution indeed; I'll commit this soon-ish]

[ballapete (Peter "Pete" Dyballa)]

Replying to reneeotten:

did you verify that this doesn't cause any trouble on other OSes than 10.5 and/or when compiling with clang?

No. Clang cannot be used on PPC (it's stuck in versions 4.x). On other OSes the patch just does not seem to be needed… (Tiger will be checked later)

[kencu (Ken)]

I can test this for you later today.

[reneeotten (Renee Otten)]

In 956b21a6bf190d61f49749bedcd9b9c3b697bfd4/macports-ports (master):

py-kiwisolver: attempt to fix build on 10.5

Closes: #61752