Author Topic: to which compiler should we step up to bundle with CB  (Read 15619 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
to which compiler should we step up to bundle with CB
« on: May 08, 2023, 09:56:47 pm »
which version of gcc should we take, cooked by which project ?

Any suggestions ?

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: to which compiler should we step up to bundle with CB
« Reply #1 on: May 08, 2023, 10:57:20 pm »
My personal opinion is to switch to msys environment... it makes everything so much easier...

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2773
Re: to which compiler should we step up to bundle with CB
« Reply #2 on: May 09, 2023, 05:51:19 am »
My personal opinion is to switch to msys environment... it makes everything so much easier...

It not going to be a happy situation for students and teachers to have to install msys2 in addition to installing CodeBlocks.
I think we should still provide a "ready-to-go" download that includes the compiler.

It might be too complicated for high school and college students and their teachers to maintain both CodeBlocks plus a msys2 environments.
 

Offline blauzahn

  • Almost regular
  • **
  • Posts: 156
Re: to which compiler should we step up to bundle with CB
« Reply #3 on: May 09, 2023, 07:23:19 am »
Debian's latest stable Linux version "bullseye" has gcc-10.2.1. The just released Raspberry Pi OS (64-bit) is based on that as well. On the pi, its repository does not list any newer version. Last weekend, I compiled wxwidgets trunk and cb trunk on my pi. @killerbot: There I also had to apply the 3 tiny patches fixing compile errors I sent you a few days ago.

My recommendation is to keep cb compiling with gcc-10.2.1 for now. At least, its support for C++17 is pretty ok IMHO. Any newer gcc would exclude many users on debian as well as many users, students and makers on the pi. That would be unfortunate. Also, please do not forget users on less performant and/or low buget systems like in Africa.

btw: cb-trunk compiles (patched) on arch with gcc-13.1.1 or clang 15.07. At the moment, wxwidgets trunk does not compile out of the box with gcc-13.1.1. gcc-12 and 10 are fine though. Right now, just out of curiosity, I try to compile cb-trunk on my pi with clang-13. So far the compilation is ongoing. Fingers crossed.

My main platforms I use cb on are ubuntu (lts), arch as well as pi.

On distrowatch.com you can get a good overview of the gcc-version shipped with distros. e.g.:

mint 11.2
manjaro: 12.2
ubuntu (lts) 11.2
arch 13.1.1
FreeBSD 11.2
CentOS 11.2

Have a nice day.



Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: to which compiler should we step up to bundle with CB
« Reply #4 on: May 09, 2023, 07:44:18 am »
we only bundle a compiler on windows, the one we used on windows to build the executables (nightlies).
At the moment this is an 8.x.

I know TDM is at 10.x
But that is also already old again, knowing gcc13 released last weeek.

I think gcc12 is most probably the most interesting one, giving a lot of c++20 features.


Personally I am not so fond of msys2, seems to complicated, compared to the more simple compiler bundles we used to ship.

Offline sodev

  • Regular
  • ***
  • Posts: 497
Re: to which compiler should we step up to bundle with CB
« Reply #5 on: May 09, 2023, 06:10:56 pm »
At the moment, wxwidgets trunk does not compile out of the box with gcc-13.1.1.

Compiles fine for me on Fedora 38 with gcc 13.1.1.

Personally I am not so fond of msys2, seems to complicated, compared to the more simple compiler bundles we used to ship.

The great thing of MSYS2 is, that you can get a lot of libraries easily. However, this setup only works easily if you use its shell, using the compiler standalone is cumbersome. For that use case, it's easier to use a standalone compiler like a plain MinGW-w64. But getting libraries compiled with such a compiler can be very hard. So well, for the "CodeBlocks @school" use case that uses nothing more than std::cout standalone is probably better, but for the Real-World use case MSYS2 might be better.

Offline blauzahn

  • Almost regular
  • **
  • Posts: 156
Re: to which compiler should we step up to bundle with CB
« Reply #6 on: May 10, 2023, 07:11:45 am »
@sodev: Indeed. Wxwidgets compiles fine ootb with gcc-13.1.1. I mixed it up with cppcheck where a static_assert fails. Thank you for correcting me.

With gcc-10 I meant the minimum version cb should be able to compile with at the moment. I appreciate bundling a newer gcc with cb on windows (only) so that users can use newer features. Being restricted to a compiler lagging several versions behind might discourage from using it and therefore cb on Windows. This might also frustrate cb-devs. Lets hope that the coming debian version will be available on Pi os soon.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: to which compiler should we step up to bundle with CB
« Reply #7 on: May 14, 2023, 12:57:29 am »
The great thing of MSYS2 is, that you can get a lot of libraries easily. However, this setup only works easily if you use its shell, using the compiler standalone is cumbersome. For that use case, it's easier to use a standalone compiler like a plain MinGW-w64. But getting libraries compiled with such a compiler can be very hard. So well, for the "CodeBlocks @school" use case that uses nothing more than std::cout standalone is probably better, but for the Real-World use case MSYS2 might be better.

I think most package supplied by MSYS2 can by used by pkg-config command from a normal Windows CMD.
For example, below code is from one of my Code::Blocks project's linker options. I link to glm, glfw3, glew and wx libraries supplied by MSYS2. The last line is actually using wx-config-msys2.exe.
Code
`pkg-config --libs glm`
`pkg-config --libs glfw3`
`pkg-config --libs glew`
`$(#WX_CONFIG) --libs all`

I think its simple and powerful to use MSYS2.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: to which compiler should we step up to bundle with CB
« Reply #8 on: May 19, 2023, 06:28:33 pm »
anyone any epxerience with this one, looks very promising : https://winlibs.com/ (I choose the one without clang), and the content of it is (a bot to much maybe (cmake / ninja/ ..):

This is the winlibs 64-bit standalone build of:
- GCC 13.1.0
- GDB 13.1
- MinGW-w64 11.0.0 (linked with ucrt)
- GNU Binutils 2.40
- GNU Make 4.4.1
- PExports 0.47
- dos2unix 7.4.4
- Yasm 1.3.0
- NASM 2.16.01
- JWasm 2.12pre
- ccache version 4.8
- CMake 3.26.3
- ninja 1.11.1
- doxygen 1.9.6

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1560
Re: to which compiler should we step up to bundle with CB
« Reply #9 on: May 19, 2023, 07:06:15 pm »
I have checked the Nuwen distro from Stephen T. Lavavej, it includes GCC 11.2.0 and Boost 1.77, and works fine except for two annoyances:

- The included binutils has a linking bug that can be solved deleting a flie from the distro
- C::B does not compile due to PCH problems (lot of errors from MapViewFileEx). I do not know if this is a problem from the distro or from GCC 11.2

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: to which compiler should we step up to bundle with CB
« Reply #10 on: May 19, 2023, 07:57:00 pm »
didn't know that one existed, cool, but seems outdated.

PCH problems, hmm, as my track record in this forum shows, I hate them, they are nothing but troubles ;-)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: to which compiler should we step up to bundle with CB
« Reply #11 on: May 20, 2023, 03:37:10 pm »
I have successfully build with this "https://github.com/brechtsanders/winlibs_mingw/releases/download/13.1.0-16.0.2-11.0.0-ucrt-r1/winlibs-x86_64-mcf-seh-gcc-13.1.0-llvm-16.0.2-mingw-w64ucrt-11.0.0-r1.zip"

  • wxwidgets 3.2.2.1
  • CB trunk

First runs seem to be ok.

I think this is a compiler bundle worth using ...
Maybe as the base for the next nightly ... ?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: to which compiler should we step up to bundle with CB
« Reply #12 on: May 22, 2023, 03:42:19 am »
I have successfully build with this "https://github.com/brechtsanders/winlibs_mingw/releases/download/13.1.0-16.0.2-11.0.0-ucrt-r1/winlibs-x86_64-mcf-seh-gcc-13.1.0-llvm-16.0.2-mingw-w64ucrt-11.0.0-r1.zip"

  • wxwidgets 3.2.2.1
  • CB trunk

First runs seem to be ok.

I think this is a compiler bundle worth using ...
Maybe as the base for the next nightly ... ?

I'm OK with this gcc suite, although I use msys2's gcc.

Note that I got a notification email that Release GCC 12.3.0 + LLVM 16.0.4 + MinGW-w64 11.0.0 MSVCRT (release 1) brechtsanders/winlibs_mingw released yesterday.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1560
Re: to which compiler should we step up to bundle with CB
« Reply #13 on: May 22, 2023, 02:09:26 pm »
@killerbot, that release uses UCRT instead of MSVCRT. This would force users < Windows 10 to install the UCRT as a prerequisite, even for software deployment. Previous release uses MSVCRT.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: to which compiler should we step up to bundle with CB
« Reply #14 on: May 22, 2023, 05:39:26 pm »
correct, but I have a feeling we should ditch pre win10 stuff. MSVCRT is suggested not to be used anymore ...

It is worth considering to try this approach out ?