Closed aprsa closed 7 months ago
As of right now, the C/C++ stuff looks like a show-stopper for my system.
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: command '/usr/bin/clang++' failed with exit code 1
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for phoebe
Can you please share your system details? Also, how are you trying to install it? pip with or without -e?
Tried both with and without -e, still fails (albeit with a different error: using -e tells me to try not using -e).
I'm on OS X 13.6.1 on a 2018 intel Mac Python 3.11.4 Apple clang version 15.0.0 (clang-1500.0.40.1) gcc version 12.3.0 (Homebrew GCC 12.3.0)
I'm a bit confused about the error it throws (that could be because it's late and I'm tired though). Looks to me like it should be gcc-12 but then complains about a clang error - see attached output.txt
The latest macos runner that github actions support is macos-12. Thus, I don't know how to test/troubleshoot macos-13 without having my hands on one. Does building sdist/wheel work? python -m build
, probably after pip install build
.
Nope, looks a lot like the same error. output.txt
I think it might be your system, not phoebe. Can you link any c/c++ executables?
A possible CXXFLAGS='-Wl,-ld_classic'
workaround is mentioned; does that help?
Yeah, this is weird. Can't link with g++-12 or g++13 but clang++ is working. So setting CC=clang worked. Problem was definitely on my end.
So setting CC=clang worked.
@Raindogjones - is this something that you didn't need to do manually before though? And if it is just a weird setup, should we provide some advice somewhere on the install page for how to handle these cases?
When we release this, I can also update the install page to suggest pip install -e .
in the Installing from Source instructions. Anything else I should add either there or elsewhere on that page?
@kecnry I don't think any of that is necessary. Seems this is a common problem of apple's xcode 15 not playing well with homebrew's gcc. I hadn't realised before because I only updated xcode ~a month ago and haven't done much coding since. Easy workarounds are to build gcc from source or to stick to clang. I also read somewhere that this is fixed in the current xcode beta so will go away soon.
Is all the renaming from "nosetests" to "tests" to actually migrate to pytest or is it required for the rest of the changes?
It is not required for the build system switch, I just seized the opportunity since I was updating the CI action that runs the tests. Keeping it labeled as nosetests is confusing and might make people want to run nose instead of pytest.
This is an upgrade from @Raindogjones' previous PR to replace distutils; this one goes farther by switching to pyproject.toml, using setuptools as backend and build/pip as frontend.
Note that C/C++ compiler versions/flags have not been ported (yet); the only currently supported way to do that is clunky (it goes back to setup.py with custom functions) but there's a PEP 725 under consideration that would streamline this significantly. @horvatm should weigh in on this whether we should re-add the tests into setup.py or await PEP 725.
Closes #644