Page 1 of 1

different versions of wxWidgets

Posted: Sun Jan 26, 2020 10:48 am
by Tecnoworld

I have a problem with different versions of wxWidgets. I will explain this.

In the past CodeBlocks comes with wxWidgets 2.8.x, I use wxWidgets 3.0.2 - No problems so far.

Now Codeblocks comes with wxWidgets 3.0.2 and installs the libs in the system and provides them through ldconf-system.
Codeblocks ist installed under /devel/cd, the wxlibs under /devel/wxcb, but codeblock needs, that wxwidgets is in the search path.

I compiled wxWidgets with unicode, opengl, added some other stuff (different Lexer etc.), changed the translation system...
The wxWidgets is in /opt/wxdeb and /opt/wxrel.

Problem: now I have different installations of wxWidgets with the same lib-names, but different builds. If one program linked against the one and found in runtime the other lib, it crashes. Of sure.

How can I configure wxWidgets, so that I can rename the libs during the building. Or, what is a normal way to handling this cases.
I can not only rename the files, because wx-config must tell the correct file-names.

Re: different versions of wxWidgets

Posted: Mon Jan 27, 2020 4:53 pm
In *nix world it is better to rely on the package version that comes from the repository.
But if you used the wxWidgets hand-compiled in the past - you should un-install it first making sure that there is nothing left, then make advantage of the version that comes with the system.

I'd rather use this than the one that comes from the C::B.

The reason being - it is being tested as working with the OS package maintainers and guarantees to be working in this same environment.
wxWidgets can have a precompiled library in the distro repository for opengl. Unicode is a default option since 3.0.
There is a support for adding a lexer to Scintilla (I think it is in wxWidgets-3.0.3 though).
And you should submit a patch to add the translation system you use for inclusion in wxWidgets - that way you won't need to maintain it and recompile every time there will be an upgrade.

I'd use the C::B version in Windows only.

Thank you.

Re: different versions of wxWidgets

Posted: Tue Jan 28, 2020 4:06 pm
by Tecnoworld
Ok, I will explain a little better...
The project runs on:


On each plattform I need C::B. C::B uses his own version of wxWidgets, if I install as a binary package.
If its a newer version of C::B then its 3.0.2, the same like I use.

I have some changes and extensions in wxWidgest, what I don´t like to submit in the repository of wxWidgets, so I must compile wxWidgest always by myself. Also I need the debug versions of the libs, for debugging purpose.

The compiling and linking against a specific version is´nt a problem. But if I run the compiled program it will be use the first version in path.
Also if I provide the package (.deb) could happens, that in the destination system still runs wxWidgets and so I will run in a problem.

The best solution is, to add a flag during the ./configure of wxWidgets, that I can change the libname. But also wx-config must then provide this names. Also the aclocal .m4 scripts...

How can I do this?

on armhf was esay. I could build C::B against my version of wxWidgets 3.0.2 and the destination system is always mainened from us, so there no complications... (its a closed system, what we provide, with own kernel and read only fs)

Re: different versions of wxWidgets

Posted: Tue Jan 28, 2020 5:22 pm
One possibility might be to link statically to wxWidgets.
But then the binary will be huge as it will link in the whole GTK package on your development system, and its probably not what you want.

Now, let me ask you - are you going to provide the binaries alone with the program your are building?
Because if you do - all you will need is to do:

Code: Select all

../configure --prefix=/usr/local/ <another set of options
make install
and then use "wx-config" from /usr/local to build your own software.

Now, here is another suggestion - all those wxWidgets extensions you are building by modifying wxWidgets sources can be built inside your software, since you don't want to submit them to the wx mainline.
That way all you will need to do is rely on the default distro-provided package and be done with it, building just your own software.

Easy and simple.

Thank you.

Re: different versions of wxWidgets

Posted: Wed Jan 29, 2020 3:48 pm
by Tecnoworld
This is what I do since beginning, but no solution.

The different builds of wxWidgets are in different folders (with the --prefix)
/opt/wxcb (for Codeblocks),
/opt/wxrel (release version)
/opt/wxdeb (debug version)
/opt/wxnouni/ (for other apps with unicode) and so on....

But codeblocks needs, that the /opt/wxcb/lib is in the for ldconfig. This means, its in the search-path.
If I compile my programm against /opt/wxrel (wx-config flags)then I need /opt/wxrel in the search path and not /opt/wxcb.

We provide our program together with the correct libs. The postinst script in the package will setup also the path for ldconfig to make the libs visible in the search path. But this runs in a problem, if on the destination target a other installation of the wxlibs (possible from an other program).

if you try find / -name "libwx*" you will se, that some programs have installed in /usr/lib and they are always in the search path.

Solong the libwx-files have the same name for different builds it´s not possible to select them correctly.

Re: different versions of wxWidgets

Posted: Wed Jan 29, 2020 5:05 pm
Yes, that's exactly what I mean.
If you have a custo wx build you are almost guarantee that you are creating a problem wit your customer.

You need to keep the standard build at hand and then whatever you do with it - put it inside your software.
I guess you have your reasons not to submit it for inclusion in wx...

Thank you.