wxWidgets-3.0: set c++ standards #27309
Conversation
this version of wx has been set up for pre-c++11 builds. The compilers used to default to a pre-c++11 standard until recent clang compilers, which use c++17 or newer. These newer default standards cause the build of wxgtk-3.0 to fail. Set the c++ standard to c++03 therefore, and the build suceeds, and uses the correct structures and standars for the wxgtk-3.0 port.
this fixes the build on compilers that default to a newer c++ standard such as clang-16
fixes build with compilers that default to a too-new standard, such as clang-16
|
Notifying maintainers: |
macportsbot
added
maintainer: open
|
I have such trouble reading the CI system for what went wrong. It looks like something went wrong with the macOS-15 builder building one of the ports. TBH, the wx30 ports are not really relevant to macOS-15 anyway, but I downloaded the log archive from the CI to see if I could at least see what the error was, but I can't sort it out. |
|
Oh, I think I see what it was. glib2 failed to build… perhaps due to the py313-packaging issue. |
There was a problem hiding this comment.
This won’t work correctly. It may build, but everything which uses wx* will likely be broken.
P. S. To be clear, I will not test every wx* port to confirm that everything is broken. The statement is based on known similar cases when C++ standard was changed either for wx* or for a dependent, without rebuilding the other.
| # Address this bug: https://trac.macports.org/ticket/70124 | ||
| patchfiles-append patch-no-osx-evtloopsrc.h.diff | ||
| configure.cxxflags-append -std=c++11 |
There was a problem hiding this comment.
- It builds perfectly fine with gcc14, which defaults to C++17. W/e is the problem with clang build, it is not the newer standard used for the build by the compiler.
- Forcing C++11 here will require revbumping all ports which use wx*. Otherwise nothing gonna work, since wx* compares C++ standard at runtime (so you won’t see errors when building, but apps won’t launch). Assuming the intent is to have it actually working and not just nominally building.
There was a problem hiding this comment.
it may still build with gcc-14… different compilers raise errors with different things at different times. But supporting clang-based builds is too important to leave it broken for that reason.
There was a problem hiding this comment.
Haha… the intent is always for things to be actually working, which is why I’m always after you to test your PRs on more than just 10,6-ppc.
There was a problem hiding this comment.
Well, maybe you use C++11 with Clangs and let GCC use whatever it wants by default, since unlike Clang, it builds this fine? Or leave GTK ports alone, others are meaningless on GCC-using systems anyway.
There was a problem hiding this comment.
No need for that, I believe. Too much spaghetti in the Portfiles just leads to needless confusion and pointless workarounds. Sorry, can't just leave the wxgtk ports alone, they are needed on older systems and are broken on some of them.
|
I do think you’re right about revbumping these wx30 ports, however, to be certain they all build cleanly with the correctly-set c++ standards. |
|
@kencu Also if you force C++11 here, you do not need -cxx11 subports at all, since they existed exactly to provide C++11 (in practice 2011+) compatibility. |
I’m not following you. For example, there are two versions of wxgtk-30. The wxgtk30-cxx11 port will be set to std=c++11. The wxgtk-30 port will be set to std=c++03. Seems just right to me… |
|
It will be nice to fix this in the same go, to avoid another revbump: https://trac.macports.org/ticket/71713 |
|
I do wonder if the non-cxx11 versions of wx30 will be needed in future, though…if nobody uses them after time, perhaps they will turn out to be superfluous… |
Ok, fair enough, I forgot about that. Well, I do not know if there is any sense in keeping the two, since we either have a compiler which supports C++11 (all x86 besides 10.4–10.5) or a compiler which does not support either of these (or does gcc-4.2 support C++03?). |
|
did you make any progress on backporting the relaxed libgcc ABI checks from wx32 into wx30? I know this ABI checking causes runtime headaches sometimes. |
What wx cares about is exact (as it seems at least) match of C++ ABI between the wx library in use and a given dependent of it. If no dependents need exactly ++03, it is arguably pointless to provide wx with that standard, that too by default. |
I showed you in another ticket how that libgcc ABI check had been considerably relaxed in later wx versions, to reduce unnecessary runtime errors. |
I think what we rather need is fix wxGTK-32 for older systems (i.e. whichever cannot use wxWidgets32, not just ppc). I have a version of it that builds and I could build a couple of dependents against it. But other dependents did not, so there is something more to be fixed. |
I did not try modifying that, since not too many wx ports are stuck with old C++ indefinitely (not ones I care about at least), and rebuilding those (plus wx itself) once a year when compiler version changes is tolerable (and good to do anyway, periodically). |
|
The problem with fixing wx32 +cocoa to build on systems below the standard they have set of 10.10+ is that they can build but don't work properly. I have had a personal build of wx32 +x11 I've been using for several years on 10.7 to test things out, but ... not for pushing at present. Anyway, all of this is noise to this PR, so I'll try to stay on topic here rather than have another PR with 278 comments in it. |
The builds of the wx30 ports are failing on 10.7, at least.
This appears to be because 10.7 is building them with clang-16, and clang-16 defaults to a too-new c++ standard, which causes all the builds to error out.
We have two versions of most of the wx30 ports, one a "standard" build, which up to now was defaulting to something pre-c++-11 in almost all cases, and one a "*-cxx11" build, where a c++11 compiler was used.
If we set the c++ standards as such in each of the subports, this fixes the builds of the wx30 ports on 10.7, at least.
I have not tested wxPython as yet, nor any other systems beyond 10.7 as yet.