Huge problem with Code::Blocks installation

[codeks]

Hi. First of all I would like to say I visited this and many other forums to try and fix this issue, to no avail.

Recently I updated my whole system to the newest software. That includes wxWidgets, codeblocks etc.
The problem is that I use real time charting tool called wxFreeChart which has long but abandoned support.

wxFreeChart uses gtk2 so I was forced to install wxWidgets with gtk2 as well(tried both versions 2.8.12 and 3.0.5 of wxWidgets with gtk2).

I have ran into difficulties using the 20.03 codeblocks version with gtk2 so I tried version 17.12-1 which didn't let me install it's .deb files.
Now I am trying to use Code::Blocks version 16.01-release with wxWidgets version 3.0.5 with gtk2. I installed wxWidgets like so:

Code

../configure --with-gtk=2 --enable-monolithic
make -j4
sudo make install
sudo ldconfig

Then I tried installing Code::Blocks 16.01 like this:

Code

export CXXFLAGS="-std=c++11"
export ACLOCAL_FLAGS="-I `wx-config --prefix`/share/aclocal"
./bootstrap
./configure --prefix=/usr --with-contrib-plugins=all,-help
make

"make" gives me and error ./sdk_common.h:37:10: fatal error: wx/wxprec.h: No such file or directory
I should note I do have wxprec.h under /usr/include/wx-3.0/wx

Code

wx-config --version

shows:

Code

3.0.5

and,

Code

wx-config --list

shows:

Code

Default config is gtk2-unicode-3.0

  Default config will be used for output

  Alternate matches:
    gtk3-unicode-3.1
    gtk3-unicode-static-3.1

  Also available in /usr/local:
    gtk2-unicode-release-2.8

In summary: I'm trying to build and install Code::Blocks with gtk2 so my system could work with older software(wxFreeCharts) but am unable to compile from source.

[oBFusCATed]

1. you can have multiple versions of wx installed
2. you can use one for cb and another for your software
3. there is a flag to give the correct wx-config executable to configure... Try ./configure --help...
4. never use the default prefix of /usr/local. It is a disaster waiting to happen.

[cacb]

wxFreeChart uses gtk2 so I was forced to install wxWidgets with gtk2 as well(tried both versions 2.8.12 and 3.0.5 of wxWidgets with gtk2).

I have built code using wxFreeChart for a number of years using my own project file. It works with wx3. I don't think it depends on gtk2 either, not 100% sure.

As oBFusCATed said, there is no requirement to use the same wxWidgets version for building C::B and your own software. They can be different.

[codeks]

Thank you for the replies.

1. you can have multiple versions of wx installed
2. you can use one for cb and another for your software
3. there is a flag to give the correct wx-config executable to configure... Try ./configure --help...
4. never use the default prefix of /usr/local. It is a disaster waiting to happen.

I used --prefix=/usr when configuring wxWidgets and it installed wxprec.h in /usr/include/wx-3.0/wx instead of /usr/local/ but when building codeblocks I still get:

Code

./sdk_common.h:37:10: fatal error: wx/wxprec.h: No such file or directory

I have built code using wxFreeChart for a number of years using my own project file. It works with wx3. I don't think it depends on gtk2 either, not 100% sure.

As oBFusCATed said, there is no requirement to use the same wxWidgets version for building C::B and your own software. They can be different.

wxFreeChart doesn't work with GTK3, I've tried already.

How can I use a different version for my software if I'm using C::B to build it? Sorry for my ignorance, first time doing something like this.

[cacb]

How can I use a different version for my software if I'm using C::B to build it? Sorry for my ignorance, first time doing something like this.

Code::Blocks and your software are entirely independent (or should be). When you build C::B you select a wxWidgets configuration, because C::B uses wxWidgets in its implementation, but you can have more than one wxWidgets version installed. For example, here is the script I use for building C::B inder ubuntu
https://github.com/arnholm/cpde_3rdparty/blob/master/gcc/codeblocks/build_cb.sh

But I use another wxWidgets build for my own software, installed elsewhere, no problem. You just have to configure your C::B projects to reference the correct wx version for your software.  I use global variables for that, but it is not a requirement.

[oBFusCATed]

Using prefix=/usr is even more dangerous, because you mess with system files. Now you've messed your original wx install... For the wx you want to develop against use a prefix in your home folder or in something like /opt...

[codeks]

I have installed latest wxWidgets 3.1.5 and GTK3 with prefix to a /home folder
and have configured wxFreeChart using
 

Code

--with-wxdir=/full/wxWidgets/prefix/path --with-wx-config=/full/wxWidgets/wx-config/path --prefix=/home/prefix/path

but when I try to run my compiled program from the executable it doesn't launch.
I ran Valgrind's Cachegrind utillity and the results are as follows:

Code

BasicGUI/bin/Debug/BasicGUI: error while loading shared libraries: libwxcode_gtk3u_freechart-3.1.so.0: cannot open shared object file: No such file or directory
==4535== 
==4535== I   refs:      76,620
==4535== I1  misses:       547
==4535== LLi misses:       539
==4535== I1  miss rate:   0.71%
==4535== LLi miss rate:   0.70%
==4535== 
==4535== D   refs:      21,542  (15,740 rd   + 5,802 wr)
==4535== D1  misses:       783  (   358 rd   +   425 wr)
==4535== LLd misses:       768  (   343 rd   +   425 wr)
==4535== D1  miss rate:    3.6% (   2.3%     +   7.3%  )
==4535== LLd miss rate:    3.6% (   2.2%     +   7.3%  )
==4535== 
==4535== LL refs:        1,330  (   905 rd   +   425 wr)
==4535== LL misses:      1,307  (   882 rd   +   425 wr)
==4535== LL miss rate:     1.3% (   1.0%     +   7.3%  )
cachegrind.out.4535

[oBFusCATed]

1. valgrind and cachegrind aren't tools for debugging this problem.
2. Are you running it from inside or outside of codeblocks? Where does it work and where it doesn't?

[codeks]

1. valgrind and cachegrind aren't tools for debugging this problem.
2. Are you running it from inside or outside of codeblocks? Where does it work and where it doesn't?

It compiles in codeblocks but there is some sort of a runtime problem when I try to launch the executable. When I try to launch it from terminal, it just hangs.
Only lead I have is the cachegrind error telling me the shared library isn't linked, although it is. That and, Valgrind shows a stack error.

[Miguel Gimenez]

The libwxcode_gtk3u_freechart-3.1.so.0 must be in the library search path. Usually calling make install does this, but you can do it manually, see the shared libraries howto

[oBFusCATed]

It compiles in codeblocks but there is some sort of a runtime problem when I try to launch the executable. When I try to launch it from terminal, it just hangs.
Only lead I have is the cachegrind error telling me the shared library isn't linked, although it is. That and, Valgrind shows a stack error.

cachegrind is not a debugger. If it hangs, meaning being stuck you're supposed to use a debugger. Attach it to the executable by pid and it will hopefully tell you where the process is stuck.

[codeks]

The libwxcode_gtk3u_freechart-3.1.so.0 must be in the library search path. Usually calling make install does this, but you can do it manually, see the shared libraries howto

I've added a copy of libwxcode_gtk3u_freechart-3.1.so.0 to usr/lib/

cachegrind is not a debugger. If it hangs, meaning being stuck you're supposed to use a debugger. Attach it to the executable by pid and it will hopefully tell you where the process is stuck.

I get this error when I try to do it:

Code

Starting debugger: /usr/bin/gdb -nx -fullname -quiet 
Setting SHELL to '/bin/sh'
done
Setting breakpoints
Attaching to program with pid: 2590
Debugger name and version: GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Attaching failed: Could not attach to process.  If your uid matches the uid of the target
Attaching to process 2590
Debugger finished with status 0

Now, it finds the shared library but it still hangs. When I run Valgrind memcheck I get a result of which I took a picture and attached to this post. There seems to be a conflict with freechart and wxWidgets of some sort.

Cachegrind gives me a segment overflow error:

Code

==6862== brk segment overflow in thread #1: can't grow to 0x4842000
==6862== (see section Limitations in user manual)
==6862== NOTE: further instances of this message will not be shown
==6862== 
==6862== Process terminating with default action of signal 15 (SIGTERM)
==6862==    at 0x738D376: pthread_cond_wait@@GLIBC_2.3.2 (futex-internal.h:183)
==6862==    by 0xE8E2D5A: ??? (in /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3)
==6862==    by 0x7386608: start_thread (pthread_create.c:477)
==6862==    by 0x5DA8292: clone (clone.S:95)
==6862== 
==6862== I   refs:      947,650,560
==6862== I1  misses:        373,529
==6862== LLi misses:         31,625
==6862== I1  miss rate:        0.04%
==6862== LLi miss rate:        0.00%
==6862== 
==6862== D   refs:      367,911,521  (263,502,989 rd   + 104,408,532 wr)
==6862== D1  misses:     34,850,952  ( 34,075,546 rd   +     775,406 wr)
==6862== LLd misses:      1,011,794  (    589,787 rd   +     422,007 wr)
==6862== D1  miss rate:         9.5% (       12.9%     +         0.7%  )
==6862== LLd miss rate:         0.3% (        0.2%     +         0.4%  )
==6862== 
==6862== LL refs:        35,224,481  ( 34,449,075 rd   +     775,406 wr)
==6862== LL misses:       1,043,419  (    621,412 rd   +     422,007 wr)
==6862== LL miss rate:          0.1% (        0.1%     +         0.4%  )
cachegrind.out.6862

Can I let it grow to the size that it wants so it works and doesn't hang?

[codeks]

Update: I've ran the project in Codeblocks GDB with full debug log. Attached here are the findings.
It looks as if Basler library could be the problem but the stack is traced even before that.
I would appreciate some direction with this.

[oBFusCATed]

The library is throwing an exception. This seems to be an initialize call probably suggest that it does this during loading.
You'll have to study its source code. Install symbols.
If this is a binary distro and you've installed from a package them most probably there is a package which provides symbols for the library. If you've build from source you'll have to rebuild it.
There is an option in the debugger settings to break every time the binary executes a throw in c++. This might also help shed some light where the problem is coming from.