News:

Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!

Main Menu

Installing Code::Blocks from source on Linux

Started by cobramostar, October 11, 2024, 11:01:53 PM

Previous topic - Next topic

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

$ 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


Krice

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

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'
CB-13834, plugins-sdk-2.25.0 : Collector-2.6.5, AddOnForQt-5.1.2
1- Win7 Business Pack1 64bits : wx-3.2.8, gcc-15.2.0,
2- OpenSuse::Leap-15.6-64bits : wx-3.2.8;gtk3-u, gcc-15.2.0,
=> !! The messages are translated by 'Deepl'

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

#10
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.

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
Code::Blocks package maintainer for Fedora and EPEL

Krice

Quote from: SharkCZ on March 17, 2025, 04:30:29 PM
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

Quote from: Krice on March 18, 2025, 07:18:36 PM
Quote from: SharkCZ on March 17, 2025, 04:30:29 PM
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.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

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...