Advice on Version for Ubuntu

[tigerbeard]

After getting started with the CB 16.01 in Ubuntu 16.04LTS I am getting constant crashed in all sort of situations. Its a bit of a surprise, since on Windows I can not recall a single crash of C::B in many years.

I hope there are a lot of people out there using CodeBlocks in Linux (including Ubuntu), so you maybe someone could give me their experience on what version their regards as the most stable to use.

thanks

[oBFusCATed]

The latest and greatest. 16.01 is full of crashes especially on ubuntu, which have been identified and fixed for 17.12.
I've posted patches for many crashes with 16.01 on launchpad, you can check with ubuntu's developers if they've been applied or not.
But generally it is better to just update (if you cannot find packages, just build them yourself).

One major source of crashes is the symbol browser. If you disable it the frequency would lower, but there are others.

[tigerbeard]

Great, thanks that is very helpful info not continue to wast time on 16.01 versions.

Before reading you reply I just installed 17.02. I am sorry to say that, but I find it unusable, because you seem to have totally disabled the symbol browser.  I thought from the release notes its just deactivated by default. I must add that the SB actually is the killer feature of C::B for me and I am totally lost without it (even more with this huge tree leaf spacing).

Interesting to learn that its troubles (using thread gui code etc.) are causing so much worse trouble than in windows, where it often hangs but it never crahed on me. Is there any (dirty) way to get the symbol browser enabled because I'd love to check out the 17.12 official?

If not, do I have the chance to get it enabled in the nightlies?

[BlueHazzard]

s there any (dirty) way to get the symbol browser enabled because I'd love to check out the 17.12 official?

If you activate the symbol browser you will get the crashes. The only solution is to rewrite the whole part of codeblocks, but there is no dev who is willing to do it (help is needed)

One possible solution is to compile codeblocks by yourself but with wxWidgets 2.8.X instead of the official wxWidgets 3.X.X of your ubuntu distribution. This should be possible and it should work without crashing....

[tigerbeard]

If you activate the symbol browser you will get the crashes.

I am aware of that.
But that does not mean its not useful. Example. try to look at foreign code with 20.000Loc with SB or with File view only. The file view does not tell you anything about how large the classes are, public/private functions, member vars name space structure, name it. And when i have 1hr to check out such a  project, I'd still do it with a CB crahing on me 10times in that time, rather than doing it without a symbol browser.
 

The only solution is to rewrite the whole part of codeblocks, but there is no dev who is willing to do it (help is needed)

I can fully understand its hard to to such a rewrite in open source. The use case above would benefit from a "lock" button to quickly enable/disable it until its being eventually fixed. Just an example of an other "solution".

One possible solution is to compile codeblocks by yourself but with wxWidgets 2.8.X instead of the official wxWidgets 3.X.X of your ubuntu distribution. This should be possible and it should work without crashing..

Cool. Although I guess this implies the nightlies also do lock the SB feature.

If compiling CB 17.12 with 2.8 is an option that a good way out indeed. I had thought that I did read somewhere that wx3.xx is a requirement for 17.12 and it would not compile, but maybe I misunderstood that.

So if when I did compile it with 2.8, how would I enable the SB then? Woudn't it still be locked?

[oBFusCATed]

Symbol browser is disabled for all wx3.x builds. It is enabled for wx2.8, builds I think. If you build the code you can find the place where we disable it and you should remove this part of the code.

[tigerbeard]

How can I find out the latest 2.8 build? I guess is not somehting with 17 in the version number?

[BlueHazzard]

You can build the current trunk code with wx2.8. It will build fine, we support both versions at the moment...

[tigerbeard]

Great. Thanks.

one final question, since i never build CB before. When building the SVN/GIT sources, will I end up with all plugins?

I am asking because when installing from the PPAs I first installed
 

Code

sudo apt install codeblocks 

Then I was surprised to see the IDE pretty lean. It was missing all plugins including Thread Search and wxSmith. After using
 

Code

sudo apt install codeblocks codeblocks-contrib codeblocks-wxcontrib-dev

I got the full IDE. Then saw the repo had a lot more packages like codeblocks-common, wxsmith, some xxx-headers and other xxx-devs. They seem to be sensivite to the version - I got in apt mixup trouble between two 16.01 builds.

[BlueHazzard]

you can try this instruction:
https://github.com/bluehazzard/codeblocks_sf/wiki/build_linux_mint_18

WARNING: this will build codeblocks with wx30
i do not know how to switch to wx2.8 if you have installed wx30 and wx28 with ./configure

to answer your question, you have to add

Code

--with-contrib-plugins=all

to your configure line

please report if it worked...

[Edit:] i updated with a section to build with wx2.8

[tigerbeard]

Thanks for the update of that section.

I got errors on ./bootstrap

Code

 configure.ac warning: macro 'AM_OPTIONS_WXCONFIG' not found in library
 configure.ac warning: macro 'AM_PATH_WXCONFIG' not found in library
 ..
 configure.ac error: possible undefinded macro: AM_PATH_WXCONFIG

Does that ring any bells?

EDIT: I am using the trunc tarball from sourceforge

[stahta01]

http://wiki.codeblocks.org/index.php/Installing_Code::Blocks_from_source_on_Linux

Edit2: The above links gives two fixes; I normally do this one on Debian.

Code

export ACLOCAL_FLAGS="-I `wx-config --prefix`/share/aclocal"

[BlueHazzard]

I have tested this on a fresh xubuntu installation. I did not had this error, but i installed wxWidgets first from the official ubuntu repo. Maybe that made a difference... If you find a working fix, please let me know

http://wiki.codeblocks.org/index.php/Installing_Code::Blocks_from_source_on_Linux

Edit2: The above links gives two fixes; I normally do this one on Debian.

Code

export ACLOCAL_FLAGS="-I `wx-config --prefix`/share/aclocal"

I am not sure if this works, because wx-config can probably not be found if you use the --with-wx-config configure option later and don't use a "installed" wxWidgets installation. You probably have to use the full path to your temporary wxWidgets installation...
so something like this

Code

export ACLOCAL_FLAGS="-I /home/USERNAME/wxWidgets/install/share/aclocal"

if you have used

Code

--prefix=/home/USERNAME/wxWidgets/install

at the configuration process of wxWidgets

[tigerbeard]

http://wiki.codeblocks.org/index.php/Installing_Code::Blocks_from_source_on_Linux

Edit2: The above links gives two fixes; I normally do this one on Debian.

Code

export ACLOCAL_FLAGS="-I `wx-config --prefix`/share/aclocal"

Thanks for the link to your description. I had been following that from BlueHazzards post. I did run it on 2 different PCs, one compiled the other did not. The difference had been what had been installed previously or not. On both I did not use a prefix, which I guess was not perfect.
After recompiling wxGTK according to statha01's line I got this out of the way location in a repeatable way, which I think is a good idea. Still this macro errors appeard, but on the instructions the fix was given as
 On Ubuntu install wx-common

In fact that solved it. Also that explains why the other PC had worked. It indeed had the package installed before.

[tigerbeard]

OK. Now it worked.
For those interested on the Xubuntu 16.04LTS install, here is some feedback

• I can confirm that the symbol browser can be enabled/disabled when the source is compiled against wxGTK2.8, which is a great relief 
• After sudo make install starting codeblocks got an "unkown symbol" error. After running sudo ldconfig it worked fine. The wiki instructions did not list this, but the instruction that BlueHazzard linked
• A very helpful step in the wiki are the three wx-config commands to verify that the wxGTK build was successful. This is especially important if there might be conflicting wxVersions on the system. Great!
• Also great and crucial for me were the notes for the errors from ./bootstrap in the Wiki. Since the script dives deeply into the autotools its hard for beginners to debug it, e.g. the 'AM_xxx_WXCONFIG' errors I got.
• I liked the instructions https://github.com/bluehazzard/codeblocks_sf/wiki/build_linux_mint_18, for their clear and easy structure.
  
  • The patch for wx2.8 proved not necessary in my case. Its only use is to fix a compile error. IMHO its quicker to check if the error occurs at all and only patch if necessary.
  • The Makefile patch is about supressing too much compiler warnings. The "if a newer gcc is used" translated for me to: "gcc 5.4.0 or older are not affected". Actually, in that case the given line is not present in the makefile at all.
  • A link to the above mentioned C::B Wiki resources might be helpful

• Further I had some issues with getting the sources. The svn did not work, because it had all scripts saved without execute file permission (-rw-rw--r-). Since those scripts were using subscripts, etc I did not try to figure out where to correct that those manually. I am not aware how to fix the SVN, but it might be specific to my system. Further the download from the CodeBlocks.org website (the 17.12 tarball) was missing quite a few scripts and I could not even get to compilation. I thought that was weird. Only the Download Snapshot tarball from the sourceforge website worked for me. No Idea if that makes sense at all. At least for me to find it when I will re-try this again in a few month. Anyway, using the trunc snapshot ist the most practical way anyway especially when its going to be used on offline PCs as well or the status needs to be archived. 

Special thanks for BlueHazzard and stahta01 (and of course oBFusCATed [as always]  for the very good help