Can't compile wxPython Slackbuild in 32-bit (but works fine for 64-bit)
I'm trying to compile wxPython. Using sbopkg, I was able to compile it just fine in my 64-bit installation of Slackware 13.37. I have a 32-bit installation of the very same distribution and version on a separate partition that I chroot into whenever I need 32-bit functionality. The chroot has been working great, everything from compiling the NVIDIA kernel module to getting Wine running some of my games has been a breeze.
Inside the 32-bit chroot, which also is using sbopkg (carefully using different temporary directories so as to not confuse the 64- and 32-bit sbopkg temp files, as /tmp is bind-mounted,) this is the error I've been getting every single time I try to compile wxPython:
I most *certainly* have gstreamer and GConf installed in the 32-bit chroot. Checked and double-checked that to be sure.
I'm wondering if somewhere along the line in my 64-bit environment, I had earlier installed an unlisted dependency of wxPython, and that's what allowed me to build wxPython successfully when it came time to build it. It's rare, but it sometimes happens on slackbuilds.org that not all dependencies are listed in a build's README, even though usually they're well-documented. I've already got a few dozen Slackbuilds installed in my 64-bit environment, but only a handful in the 32-bit chroot by comparison.
Just in case, I installed gst-python, gst-plugins-bad and gst-plugins-ugly, since those seemed at least potentially related and they were present in my 64-bit environment. I even built and installed the optional libgnomeprint package (as well as libgnomeprint's dependency tree) and tried the GNOMEPRINT=yes option, just taking a stab at the dark at doing *something* different that might kick its ass into compiling straight. None of those actions made any difference, still got the same error in the same place.
Regarding multilib, I am aware of how to give Slackware a multilib environment, I've performed it several times before on earlier installs, but right now I prefer to keep things pure 64-bit. I've otherwise had no other issues with the chroot, so I'm inclined to doubt it's the chroot that's causing the issue. Making -compat32 versions of Slackbuilds was becoming too big of a pain in the ass and so far the chroot has saved me from a lot of those pains. If anything, things have been smoother sailing in the chroot than when I used to multilib. So long as I can figure out what the problem is with wxPython and conclusively determine the chroot isn't at fault (or if it is, what to do about it), I'm going to write a guide on how to set up a 32-bit Slackware chroot for other people who prefer not to multilib but still would like 32-bit support in another fashion. wxPython is a rather big dependency of many things, though, so I wouldn't want to lead people astray if this turns out to be unresolvable.
One thing I cannot do is boot directly into the 32-bit environment. I'm not sure why, I had liloconfig create an entry for it and everything, still get a kernel panic when I try to boot it. In any case, that isn't an option for diagnosing things further unless someone can help me out with that too, I'm afraid.
Oh yeah, wxGTK produces the same error, so that's no substitute either, unfortunately.
I've rambled on long enough. Any help is greatly appreciated. Thank you very much.
Well I'm only guessing ...
but I think you may miss some deps from STock Slackware, as SBo doesn't list them .
But maybe I'm wrong.
A quick # locate gst.h
gives me on my system :
so I think gstreamer should provide the file.
Maybe look into /src/unix/mediactrl.cpp:21:61 and see where it looks for gst.h
I had some problems with all this WX stuff and ended up using the binary packages from slacky.it which did the trick for me.
Regarding lilo, did you copy the 32bit kernel over to the 64 bit /boot folder ?
If not, lilo will use the wrong kernel to boot the second partition, if I remember correctly.
(Because it searches on the partition from the "boot= /dev/sdx" entry.
To boot two different linux partitions, I use grub as it's to me clearer how to configure it.
(For lilo it was way more complicated, but I don't remember the details)
Hope it helps...
Strange, because I did a full (terse) install of all the packages for the 32-bit environment. Loaded up the 32-bit install DVD and pointed it to an empty, freshly-formatted partition to use for /. Didn't leave a single package out because I wanted a fully-fledged 32-bit environment, as a "just in case" measure against any possible dependencies. That's why I'm suspecting I need a Slackbuild dependency and not one from the DVD. Here's the output of # locate gst.h, to prove it's there...
No, I didn't copy the 32-bit /boot contents over to the 64-bit /boot. 64-bit is installed to /dev/sda2, 32-bit to /dev/sda1. I assumed that the boot= line, as it points to /dev/sda (but not sda1, sda2, etc.) would resolve the filesystem based on the root= line for each menu item, not the general boot= line near the top. I have experience with grub from when I used to use Ubuntu a while back, I do remember it being a little easier to read its configuration files, perhaps a switch to grub would be worthwhile.
The file pygst.h is in the gst-python package from SBo .
I would still recommend http://www.slacky.eu/asche/pkgs/inde...er=15&pkg=2495 as I always use their packages, when compiling gets too complicated.
About lilo I didn't remember correctly, of course the boot points to the whole disk, right!
But it doesn't use the /boot dir from every "root" entry, don't remember why exactly, but the solution for this was to copy the kernel (and maybe the initrd , System.map and config) to the partition from which you install lilo. (Maybe it was even System.map which was the wrong one ? REALLY don't remeber in detail :5 )
I finally switched to grub, because you can have entries like this to make it really clear what you want like:
kernel /boot/vmlinuz-3.4 root=/dev/sda1 vga=795
kernel /boot/vmlinuz-3.3 root=/dev/sda2 vga=795
Aditionally grub-install has a "--recheck" switch to force reprobing of the device map
And it comes with Slackware in EXTRA :)
I grabbed the package from slacky.eu, but the program I'm trying to run is still throwing a fit about a lack of 'libwx_baseu-2.8.so.0'. The SBo of wxPython I built in 64-bit contains this. The 32-bit slacky.eu package does not, instead it contains 'libwx_base_2.8.so.0' (notice the lack of a 'u').
Why is this goddamn package the only thing that isn't working no matter what I do? Holy shit, has anyone else had this much trouble with wxPython or are the Linux gods just mad at me?
Strangely, I have gst-python in both environments but no pygst.h in /usr/include/gstreamer-0.10/gst/ for either of them. I wonder why you have it and I don't? Considering wxPython built fine without it on 64-bit I'm starting to think I'm chasing a red herring, so let's forget about this pygst.h file in that case.
Need wxPython. I will give you fame and power.
In this case the package you need is not wxPython but wxWidgets(slacky) or wxGtk(Slackware) !
wxPython is only a "stripped" down version of this wx stuff .
You can grab them as binaries here :
or here :
I checked both and they both contain 'libwx_baseu-2.8.so.0'
Phew. The wxPython from slacky worked. Thank you. I'll keep that site in mind whenever I'm having more problems. Thanks for reminding me of alien's repo, too, for some reason I keep forgetting about that one.
You know what really sucks, though? The application I've been trying to get running, hunting all these dependencies down and stuff... after finally getting it loaded up, turns out it's a total piece of ass that barely felt worth all the work. At least I learned a few things through my troubles, though.
I rated your post helpful, but I'm not sure if I should mark this thread solved. Technically, I still can't get this to compile, the binary package was more of a secondary means to an end. Ideally it would be good to compile, then I could manage any future updates with sbopkg and all that good stuff, but for practical purposes, this does what I need it to do.
Well it may be of importance for which version of WX*** your game had been released.
As I said, this package has always been a hassle ( not only in Slackware, I guess).
If it was released for the WX** 2.6 series, you could compile wxwidgets with a compatibility option for 2.6 like
|All times are GMT -5. The time now is 01:31 AM.|