Installing Code::Blocks from source on Linux

[cobramostar]

I tried to follow the procedures from the page https://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Linux#Code::Blocks_installation , but from this part I didn't succeed because it asked me for sudo user, in fact it didn't want to miss cmd without sudo user

Code

$ update-alternatives --install /usr/bin/wx-config wx-config /opt/wx/2.8/bin/wx-config 50

has anyone been able to install Code::Blocks using these instructions ?

I would be grateful for any help

[Wkerry]

Have a read of the following as they are way more up to date than the wiki page:
https://github.com/PBfordev/wxpbguide
https://forums.wxwidgets.org/viewtopic.php?t=47061


This previous thread may be of some use:
https://forums.codeblocks.org/index.php?topic=25811.0

[Krice]

I've tried to compile C::B in Fedora (from svn), I get this error, how to decipher it?

Code

/usr/bin/ld: warning: libtiff.so.5, needed by /usr/local/lib/libwx_gtk3u_aui-3.2.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFGetVersion@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFReadDirectory@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFReadRGBAImageOriented@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFDefaultStripSize@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFWriteScanline@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `_TIFFfree@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFGetField@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFScanlineSize@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFClose@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFClientOpen@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFRGBAImageOK@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFGetFieldDefaulted@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFSetField@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFSetWarningHandler@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFSetErrorHandler@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `_TIFFmalloc@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFSetDirectory@LIBTIFF_4.0'
/usr/bin/ld: /usr/local/lib/libwx_gtk3u_core-3.2.so: undefined reference to `TIFFReadScanline@LIBTIFF_4.0'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:731: codeblocks] Error 1
make[3]: Leaving directory '/home/krice/programs/cb/trunk/src/src'
make[2]: *** [Makefile:867: all-recursive] Error 1
make[2]: Leaving directory '/home/krice/programs/cb/trunk/src/src'
make[1]: *** [Makefile:539: all-recursive] Error 1
make[1]: Leaving directory '/home/krice/programs/cb/trunk/src'
make: *** [Makefile:671: all-recursive] Error 1

[Miguel Gimenez]

Looks like a dependency of wxWidgets, not of C::B.

Try installing package libtiff-dev (or whatever name Fedora uses for the package).

[Krice]

These libtiff packages are already installed:

libtiff.x86_64         4.6.0-6.fc41 fedora
libtiff-devel.x86_64  4.6.0-6.fc41 fedora

[Miguel Gimenez]

Does libtiff.so.5 exist in /usr/local/lib (or another searchable path)? If not, you can add a link to the proper libtiff.

[Krice]

Libtiff is in usr/lib64 but it has libtiff.so, libtiff.so.6 and libtiff.so.6.0.2. Do I need version 5 or what. Linux library stuff is so confusing.

[Miguel Gimenez]

Probably copying libtiff.so.6 to libtiff.so.5 is enough, but I would ask in the wxWidgets' forum.

[LETARTARE]

With 'Leap-15.6' we have the two versions which seem to coexist : 'libtiff.so.5' and  'libtiff.so.6'

[cacb]

For building Code::Blocks from source under Kubuntu use build_cb.sh found  at
https://gitlab.com/arnholm/cpde_3rdparty/-/tree/master/gcc/codeblocks

Maybe it is helpful to some.

[Krice]

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.

[SharkCZ]

You can get the latest nightly C::B for Fedora from https://copr.fedorainfracloud.org/coprs/sharkcz/danny/. As for the build procedure you can take a look at the spec file, it shows what package you need to have installed and what commands to run, see https://src.fedoraproject.org/rpms/codeblocks/blob/rawhide/f/codeblocks.spec

[Krice]

it shows what package you need to have installed

Am I supposed to know how to read that? I think compiler errors could also hint that wxWidgets is missing, but it should be installed... Maybe I could try to write a wx program to see if it works. Anyway, how is this so difficult? I think this is more difficult than when I tried to compile Code::Blocks in OSX and that was a journey.

[stahta01]

it shows what package you need to have installed

Am I supposed to know how to read that? I think compiler errors could also hint that wxWidgets is missing, but it should be installed... Maybe I could try to write a wx program to see if it works. Anyway, how is this so difficult? I think this is more difficult than when I tried to compile Code::Blocks in OSX and that was a journey.

The [linking] error posted implied wxWidgets was from an local build instead of being an Linux Distro package.
Did you build it recently? If yes, I have nothing to suggest. If no, I suggest building it again and see if the error changes or goes away.
And, the posting the reason you did the local build of wxWidgets might help people to help you.

Tim S.

[Krice]

I could have compiled wx from source but there was no source directory. Downloaded wx source, ran configure and then make uninstall. But it doesn't help. I think it did remove something from usr/local/lib, but it left wx directory with another empty wx directory at the end of it. wx can be also found from usr/lib64 and /lib64. How does it confuse compiler if it's installed in those locations, shouldn't the compiler choose one and not mix them, which could cause some problems? At this point I probably have to delete package wx, see if anything is left and delete those files manually, then reinstall it. Right? F-- 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.

[Miguel Gimenez]

Applied in r13639, thank you.