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