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
$ 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
I've tried to compile C::B in Fedora (from svn), I get this error, how to decipher it?
/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
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.
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:
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
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?),
@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
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
if HAVE_ASTYLE
libAstyle_la_LIBADD += -lastyle
EXTRA_DIST += astyle/ASBeautifier.cpp \
astyle/ASEnhancer.cpp \
astyle/ASFormatter.cpp \
astyle/ASResource.cpp \
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
@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.
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
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.