Installing Code::Blocks from source on Linux

[christo]

In some unrelated projects people have solved this by creating a symlink to libtiff which in this case is libtiff.so.6.0.2 (other files are symlinks themselves) so I did that in my usr/lib64, but now it's just giving an error already in the compile phase, in astyle.h:

Code

In file included from asstreamiterator.h:15,
                 from asstreamiterator.cpp:10:
/usr/include/astyle.h:295:44: error: 'std::string_view' has not been declared
  295 |         const std::string* findHeader(std::string_view line, int i,
      |                                            ^~~~~~~~~~~

This seems to indicate that something doesn't include std::string header, right?

Edit: also, there could be some kind of confusion in including astyle.h in asstreamiterator.h. If you use angle brackets it's trying to find the file in usr/library while there is also plugins/astyle/astyle directory where you can find another astyle.h which is not included unless you write #include "astyle/astyle.h", well I guess depending how this project is handling that kind of stuff, could be something else happening.

This is because if astyle is installed in the PC,  codeblocks uses it instead of that in sdk. Astyle installed in your PC is new and uses c++17 features, but codeblocks still uses c++11 flags. That is why compilation fails.

You can try following patch

Code

diff --git a/configure.ac b/configure.ac
index 1d4898a28..b8ed0b7cf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -361,7 +361,7 @@ CPPFLAGS="$CPPFLAGS -DPIC $CB_TINYXML_CFLAGS"
 CXXFLAGS="$CXXFLAGS $PIC_CFLAGS -fexceptions"
 AC_SUBST(codeblocks_PCH_FLAGS, "$PCH_FLAGS")
 
-AX_CXX_COMPILE_STDCXX(11, noext)
+AX_CXX_COMPILE_STDCXX(17, noext)
 
 dnl AM_PATH_GTK(1.2.7, ,
 dnl             AC_MSG_ERROR(Cannot find GTK: Is gtk-config in path?),

[stahta01]

If I remember correctly, "AX_CXX_COMPILE_STDCXX(17, noext)" will result in wxSmith not building.

Tim S.

[Krice]

Fixed astyle by searching which files were including astyle.h with angle brackets, there are three headers in astyle directory: asstreamiterator.h, dlgformattersettings.h and formattersettings.h. Changed those to "astyle/astyle.h" which seemed like what they should be in the first place, because now they are using the astyle that is in the plugin directory.

I still got wx errors after that so I thought why not compile wx from the source, because it seems to want to use the usr/local version anyway. Wx compiled without errors which means I must have compiled it earlier. Then sudo make install and that was it. Code::Blocks compiled after that.

I don't know if this is supposed to happen, but the new Code::Blocks overwrites the one installed from Fedora Software, because when you click the icon it runs the new version.

[Miguel Gimenez]

Angle brackets changed to double quotes in r13635, thank you for reporting.

[christo]

@Miguel Gimenez I think above patch can cause compiling against astyle headers provided in codeblocks,  and link to astyle libraries present in the system. This might cause issues because of ABI incompatibility.

[stahta01]

@Miguel Gimenez I think above patch can cause compiling against astyle headers provided in codeblocks,  and link to astyle libraries present in the system. This might cause issues because of ABI incompatibility.

From configure.ac

Code

AC_CHECK_HEADER(astyle.h, [HAVE_ASTYLE=yes], [HAVE_ASTYLE=no])

dnl check if system astyle is at least 3.0, otherwise use bundled astyle-library
dnl ASPeekStream is declared since 3.0
if test "$HAVE_ASTYLE" = "yes" ; then
	AC_CHECK_TYPE([astyle::ASPeekStream], , [HAVE_ASTYLE=no], [#include "astyle.h"])
else
	HAVE_ASTYLE=no
fi

from makefile.am

Code

if HAVE_ASTYLE
libAstyle_la_LIBADD += -lastyle
EXTRA_DIST += astyle/ASBeautifier.cpp \
		astyle/ASEnhancer.cpp \
		astyle/ASFormatter.cpp \
		astyle/ASResource.cpp \

[Miguel Gimenez]

OK, but it is already giving problems the other way because the newer astyle library needs C++17 and we use C++11.

I would remove library detection from configure.ac and HAVE_ASTYLE check from Makefile.am, opinons?

[stahta01]

OK, but it is already giving problems the other way because the newer astyle library needs C++17 and we use C++11.

I would remove library detection from configure.ac and HAVE_ASTYLE check from Makefile.am, opinons?

I would check for CXX11 or CXX14 and [if yes] disable looking for system astyle. The exact names are likely in an m4 file.
Edit: HAVE_CXX11 and HAVE_CXX14

Tim S.

[Miguel Gimenez]

Is there a HAVE_CXX17?

EDIT: I do not use autotools, if someone can post a patch for configure.ac or Makefile.am including checking for C++17 it would be safer.

[stahta01]

Is there a HAVE_CXX17?

EDIT: I do not use autotools, if someone can post a patch for configure.ac or Makefile.am including checking for C++17 it would be safer.

Then you would have to keep editing the configure.ac each time a new version is released; so now HAVE_CXX17, HAVE_CXX20, and HAVE_CXX23.

Tim S.

[stahta01]

Is there a HAVE_CXX17?

EDIT: I do not use autotools, if someone can post a patch for configure.ac or Makefile.am including checking for C++17 it would be safer.

Then you would have to keep editing the configure.ac each time a new version is released; so now HAVE_CXX17, HAVE_CXX20, and HAVE_CXX23.

Tim S.

Likely best to wait till a person who is more of an expert can do the change.

Tim S.

[Miguel Gimenez]

Reverted commit 13635.

[Krice]

Yeah, I don't actually know how that worked, because doesn't it also need the library file? Maybe just building wx from source fixed everything. I guess I could try it again by using angle brackets and rebuilding Code::Blocks, but I'm not in the mood right now. Anyway, when you are using angle brackets you should somehow make sure it's using headers in the project (and not in lib or elsewhere in path), because why would you otherwise have them in a project directory? And even then it feels wrong, because two styles of using #include are there for a reason.

[Miguel Gimenez]

This code in configure.ac:88 should work:

Code

if test "$HAVE_ASTYLE" = "yes" -a "$HAVE_CXX11" != "1" -a "$HAVE_CXX14" != "1" ; then
	AC_CHECK_TYPE([astyle::ASPeekStream], , [HAVE_ASTYLE=no], [#include "astyle.h"])
else
	HAVE_ASTYLE=no
fi

Looking for HAVE_CXX11 usage examples I have seen comparations with "1", "yes" and "TRUE", GNU uses "1".

[christo]

@Miguel Gimenez

I tested the change and it did not work.

Looks like a simple solution is just to move AX_CXX_COMPILE_STDCXX before checking astyle, then it will discard installed astyle if not supported. Please see configure logs with latest astyle below.

Code

checking astyle.h usability... no
checking astyle.h presence... yes
configure: WARNING: astyle.h: present but cannot be compiled
configure: WARNING: astyle.h:     check for missing prerequisite headers?
configure: WARNING: astyle.h: see the Autoconf documentation
configure: WARNING: astyle.h:     section "Present But Cannot Be Compiled"
configure: WARNING: astyle.h: proceeding with the compiler's result
checking for astyle.h... no

I tested the change with an older version of astyle, which does not require c++17 ( v 3.4.14), and it selects the installed astyle

Code

checking astyle.h usability... yes
checking astyle.h presence... yes
checking for astyle.h... yes
checking for astyle::ASPeekStream... yes

Im no expert in autotools, but this looks like a harmless change. Attaching the patch.