[opensuse-packaging] What is wxGTK/wxWidgets all about?
Hi, my package home:plater kicad based on Science kicad, which I need for money making work, eshceema gui freezes after my box goes on standby which I suspect without lengthy debugging is due to wxGTK. I see that the openSUSE wxGTK is actually wxPython and not even wxGTK although the url in the spec file points to the wxwidgets site. Kicad is supposed to use wxWidgets but this is only available from packman and causes problems with other packages which build from wxGTK (wxPython). Why are there all of these different types of wx's? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dave Plater wrote:
Hi, my package home:plater kicad based on Science kicad, which I need for money making work, eshceema gui freezes after my box goes on standby which I suspect without lengthy debugging is due to wxGTK. I see that the openSUSE wxGTK is actually wxPython and not even wxGTK although the url in the spec file points to the wxwidgets site. Kicad is supposed to use wxWidgets but this is only available from packman and causes problems with other packages which build from wxGTK (wxPython). Why are there all of these different types of wx's?
wxPython is a one-off branch of wxGTK. They take the releases of wxGTK, add python bindings there and release it with the same version number as wxGTK, just extended with fourth minor version number. wxPython-2.8.10.1 = wxGTK-2.8.10 + Python bindings version (2.8.10.)1 The whole multi-platform projects is called wxWidgets, wxGTK is just a GTK+ implementation. Packman wxWidgets packages is the GTK+ implementation, nearly the same as wxGTK from openSUSE. But they are not equal. wxWidgets have many compilation options and can have several binary incompatible versions. At least these were considered as binary incompatible: with Unicode and with STL with Unicode and without STL without Unicode and with STL without Unicode and without STL There are badly written applications that work only with one of these combinations. The bad thing about that is the fact, that applications compiled against Packman libraries may be incompatible with libraries from openSUSE, but there is no indication, that you are running incompatible version (libraries have the same name). So if you are using packages from openSUSE, use wxGTK from openSUSE, if you are using packages from Packman, use wxWidgets from Packman. I am thinking about improvement of this situation, but I don't see a simple solution yet. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 10/26/2010 02:39 PM, Stanislav Brabec wrote:
Dave Plater wrote:
Hi, my package home:plater kicad based on Science kicad, which I need for money making work, eshceema gui freezes after my box goes on standby which I suspect without lengthy debugging is due to wxGTK. I see that the openSUSE wxGTK is actually wxPython and not even wxGTK although the url in the spec file points to the wxwidgets site. Kicad is supposed to use wxWidgets but this is only available from packman and causes problems with other packages which build from wxGTK (wxPython). Why are there all of these different types of wx's?
wxPython is a one-off branch of wxGTK. They take the releases of wxGTK,
add python bindings there and release it with the same version number as wxGTK, just extended with fourth minor version number.
wxPython-2.8.10.1 = wxGTK-2.8.10 + Python bindings version (2.8.10.)1
The whole multi-platform projects is called wxWidgets, wxGTK is just a GTK+ implementation.
Packman wxWidgets packages is the GTK+ implementation, nearly the same as wxGTK from openSUSE. But they are not equal. wxWidgets have many compilation options and can have several binary incompatible versions. At least these were considered as binary incompatible: with Unicode and with STL with Unicode and without STL without Unicode and with STL without Unicode and without STL
There are badly written applications that work only with one of these combinations.
The bad thing about that is the fact, that applications compiled against Packman libraries may be incompatible with libraries from openSUSE, but there is no indication, that you are running incompatible version (libraries have the same name).
So if you are using packages from openSUSE, use wxGTK from openSUSE, if you are using packages from Packman, use wxWidgets from Packman.
I am thinking about improvement of this situation, but I don't see a simple solution yet.
Thanks for explaining, I keep my system on wxGTK. My instinct tells me that my kicad freeze is something to do with a kde4 4.5.2 clashing with wxGTK, that's the only major change since kicad started freezing. There's a new release of wxGTK 2.9.1.1 I've eventually tracked down the wxPython flavour and am trying that. I'll change the spec file url to wxpython.org and submit it when finished. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 10/26/2010 02:39 PM, Stanislav Brabec wrote:
Dave Plater wrote:
Hi, my package home:plater kicad based on Science kicad, which I need for money making work, eshceema gui freezes after my box goes on standby which I suspect without lengthy debugging is due to wxGTK. I see that the openSUSE wxGTK is actually wxPython and not even wxGTK although the url in the spec file points to the wxwidgets site. Kicad is supposed to use wxWidgets but this is only available from packman and causes problems with other packages which build from wxGTK (wxPython). Why are there all of these different types of wx's?
wxPython is a one-off branch of wxGTK. They take the releases of wxGTK, add python bindings there and release it with the same version number as wxGTK, just extended with fourth minor version number.
wxPython-2.8.10.1 = wxGTK-2.8.10 + Python bindings version (2.8.10.)1
The whole multi-platform projects is called wxWidgets, wxGTK is just a GTK+ implementation.
Packman wxWidgets packages is the GTK+ implementation, nearly the same as wxGTK from openSUSE. But they are not equal. wxWidgets have many compilation options and can have several binary incompatible versions. At least these were considered as binary incompatible: with Unicode and with STL with Unicode and without STL without Unicode and with STL without Unicode and without STL
There are badly written applications that work only with one of these combinations.
The bad thing about that is the fact, that applications compiled against Packman libraries may be incompatible with libraries from openSUSE, but there is no indication, that you are running incompatible version (libraries have the same name).
So if you are using packages from openSUSE, use wxGTK from openSUSE, if you are using packages from Packman, use wxWidgets from Packman.
I am thinking about improvement of this situation, but I don't see a simple solution yet.
I've got wxPython-src-2.9.1.1 in home:plater wxGTK it actually succeeds for 11.2 but 11.3 and factory complain about $RPM_BUILD_ROOT in the python libs. I've commented my major changes and the removed patches in the spec file, contrib is no longer in the release and only available from svn, no .changes file update yet. I would appreciate your looking it over and comments / criticisms. There's a new build script in wxPython-src-2.9.1.1/wxPython as well. It's one hell of a package to build. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dave Plater píše v St 27. 10. 2010 v 13:22 +0200:
On 10/26/2010 02:39 PM, Stanislav Brabec wrote:
Dave Plater wrote:
Hi, my package home:plater kicad based on Science kicad, which I need for money making work, eshceema gui freezes after my box goes on standby which I suspect without lengthy debugging is due to wxGTK. I see that the openSUSE wxGTK is actually wxPython and not even wxGTK although the url in the spec file points to the wxwidgets site. Kicad is supposed to use wxWidgets but this is only available from packman and causes problems with other packages which build from wxGTK (wxPython). Why are there all of these different types of wx's?
wxPython is a one-off branch of wxGTK. They take the releases of wxGTK, add python bindings there and release it with the same version number as wxGTK, just extended with fourth minor version number.
wxPython-2.8.10.1 = wxGTK-2.8.10 + Python bindings version (2.8.10.)1
The whole multi-platform projects is called wxWidgets, wxGTK is just a GTK+ implementation.
Packman wxWidgets packages is the GTK+ implementation, nearly the same as wxGTK from openSUSE. But they are not equal. wxWidgets have many compilation options and can have several binary incompatible versions. At least these were considered as binary incompatible: with Unicode and with STL with Unicode and without STL without Unicode and with STL without Unicode and without STL
There are badly written applications that work only with one of these combinations.
The bad thing about that is the fact, that applications compiled against Packman libraries may be incompatible with libraries from openSUSE, but there is no indication, that you are running incompatible version (libraries have the same name).
So if you are using packages from openSUSE, use wxGTK from openSUSE, if you are using packages from Packman, use wxWidgets from Packman.
I am thinking about improvement of this situation, but I don't see a simple solution yet.
I've got wxPython-src-2.9.1.1 in home:plater wxGTK it actually succeeds for 11.2 but 11.3 and factory complain about $RPM_BUILD_ROOT in the python libs.
I will look at it. In general, the most common reason for this problem is an incorrect use of libtool while linking against uninstalled libraries. Incorrect: -L ../lib -lfoo Correct: $(top_builddir)/lib/libfoo.la
It's one hell of a package to build.
Yes, I am thinking about removal of non-unicode build from the default spec (and even moving it from openSUSE to Contrib, as it is deprecated for several years) file and making two spec files. Maybe even splitting wxPython build out of wxGTK would make sense. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 10/27/2010 02:02 PM, Stanislav Brabec wrote:
Dave Plater píše v St 27. 10. 2010 v 13:22 +0200:
On 10/26/2010 02:39 PM, Stanislav Brabec wrote:
Dave Plater wrote:
Hi, my package home:plater kicad based on Science kicad, which I need for money making work, eshceema gui freezes after my box goes on standby which I suspect without lengthy debugging is due to wxGTK. I see that the openSUSE wxGTK is actually wxPython and not even wxGTK although the url in the spec file points to the wxwidgets site. Kicad is supposed to use wxWidgets but this is only available from packman and causes problems with other packages which build from wxGTK (wxPython). Why are there all of these different types of wx's?
wxPython is a one-off branch of wxGTK. They take the releases of wxGTK, add python bindings there and release it with the same version number as wxGTK, just extended with fourth minor version number.
wxPython-2.8.10.1 = wxGTK-2.8.10 + Python bindings version (2.8.10.)1
The whole multi-platform projects is called wxWidgets, wxGTK is just a GTK+ implementation.
Packman wxWidgets packages is the GTK+ implementation, nearly the same as wxGTK from openSUSE. But they are not equal. wxWidgets have many compilation options and can have several binary incompatible versions. At least these were considered as binary incompatible: with Unicode and with STL with Unicode and without STL without Unicode and with STL without Unicode and without STL
There are badly written applications that work only with one of these combinations.
The bad thing about that is the fact, that applications compiled against Packman libraries may be incompatible with libraries from openSUSE, but there is no indication, that you are running incompatible version (libraries have the same name).
So if you are using packages from openSUSE, use wxGTK from openSUSE, if you are using packages from Packman, use wxWidgets from Packman.
I am thinking about improvement of this situation, but I don't see a simple solution yet.
I've got wxPython-src-2.9.1.1 in home:plater wxGTK it actually succeeds for 11.2 but 11.3 and factory complain about $RPM_BUILD_ROOT in the python libs.
I will look at it. In general, the most common reason for this problem is an incorrect use of libtool while linking against uninstalled libraries.
Incorrect: -L ../lib -lfoo
Correct: $(top_builddir)/lib/libfoo.la
It's one hell of a package to build.
Yes, I am thinking about removal of non-unicode build from the default spec (and even moving it from openSUSE to Contrib, as it is deprecated for several years) file and making two spec files. Maybe even splitting wxPython build out of wxGTK would make sense.
I was surprised how long the python build in the install section took, when I eventually sorted out it's dependencies. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dave Plater wrote:
On 10/27/2010 02:02 PM, Stanislav Brabec wrote:
Yes, I am thinking about removal of non-unicode build from the default spec (and even moving it from openSUSE to Contrib, as it is deprecated for several years) file and making two spec files. Maybe even splitting wxPython build out of wxGTK would make sense. I was surprised how long the python build in the install section took, when I eventually sorted out it's dependencies.
Well, the first phase of the migration was just done. Repository X11:wxWidgets now contain new wxWidgets packages. I am enabling STL support by default and creating non-STL version as an compat option. Now I will progress in following two things: - Package wxpython separately - Test, whether compat version works as expected on one of problematic packages. The package will be renamed to follow upstream. the new name is wxWidgets (previously, wxWidgets was the name of the upstream project, but packages were called wxGTK, wxMotif, wxMSW, etc.). -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11/16/2010 06:46 PM, Stanislav Brabec wrote:
Dave Plater wrote:
On 10/27/2010 02:02 PM, Stanislav Brabec wrote:
Yes, I am thinking about removal of non-unicode build from the default spec (and even moving it from openSUSE to Contrib, as it is deprecated for several years) file and making two spec files. Maybe even splitting wxPython build out of wxGTK would make sense. I was surprised how long the python build in the install section took, when I eventually sorted out it's dependencies.
Well, the first phase of the migration was just done. Repository X11:wxWidgets now contain new wxWidgets packages.
I am enabling STL support by default and creating non-STL version as an compat option.
Now I will progress in following two things: - Package wxpython separately - Test, whether compat version works as expected on one of problematic packages.
The package will be renamed to follow upstream. the new name is wxWidgets (previously, wxWidgets was the name of the upstream project, but packages were called wxGTK, wxMotif, wxMSW, etc.).
One problem so far "nothing provides wxWidgets needed by wxWidgets-lang" Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed Nov 17 2010 at 11:59 +0200 Dave Plater wrote:
On 11/16/2010 06:46 PM, Stanislav Brabec wrote:
Dave Plater wrote:
On 10/27/2010 02:02 PM, Stanislav Brabec wrote:
Now I will progress in following two things: - Package wxpython separately - Test, whether compat version works as expected on one of problematic packages.
The package will be renamed to follow upstream. the new name is wxWidgets (previously, wxWidgets was the name of the upstream project, but packages were called wxGTK, wxMotif, wxMSW, etc.).
One problem so far "nothing provides wxWidgets needed by wxWidgets-lang"
Packaging wxWidgets was a nightmare. Now it is (I hope) finally done and submitted to the Factory (requests 56811-56815). Libraries are outside libdir to never conflict. Additional package magic helps to identify dependencies. See README.SUSE in the package for more. Every openSUSE package should have these two lines to the spec file to help to identify correct variant of the library (I plan to do it in Factory): %define _use_internal_dependency_generator 0 %define __find_requires %wx_requires With these two lines STL x wxcontainer ABI clash should never cause crash. Without them, you need to install compatibility ld.so.conf.d file and you will be limited to only one ABI variant. Important changes: There will be 3 variants available: wxWidgets: STL+Unicode variant (recommended) wxWidgets-ansi: wxcontainer + ANSI (strongly deprecated) wxWidgets-wxcontainer: wxcontainer + Unicode (deprecated) And these 3 variants available in OBS: wxWidgets-2_9 wxWidgets-2_9-ansi wxWidgets-2_9-wxcontainer Branch 2.9 has a lot of changes, and many advanced applications will need porting. And this package is built separately. python-wxWidgets I will send a mail as a new thread when this will be in Factory. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11/16/2010 06:46 PM, Stanislav Brabec wrote:
Dave Plater wrote:
On 10/27/2010 02:02 PM, Stanislav Brabec wrote:
Yes, I am thinking about removal of non-unicode build from the default spec (and even moving it from openSUSE to Contrib, as it is deprecated for several years) file and making two spec files. Maybe even splitting wxPython build out of wxGTK would make sense.
I was surprised how long the python build in the install section took, when I eventually sorted out it's dependencies.
Well, the first phase of the migration was just done. Repository X11:wxWidgets now contain new wxWidgets packages.
I am enabling STL support by default and creating non-STL version as an compat option.
Now I will progress in following two things: - Package wxpython separately - Test, whether compat version works as expected on one of problematic packages.
The package will be renamed to follow upstream. the new name is wxWidgets (previously, wxWidgets was the name of the upstream project, but packages were called wxGTK, wxMotif, wxMSW, etc.).
The package I'm having trouble with "home:plater kicad" failed to build with wxWidgets but has succeeded with wxWidget-ansi. This is after I created a dummy %name rpm containing README.SUSE, made it require all the libs and made it a requirement of the devel package after stripping the libs requirement from the devel package, to satisfy the lang packs need for the %name rpm. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (2)
-
Dave Plater -
Stanislav Brabec