I am trying to install pycairo 1.10 for Python 3.3 on redhat 6. There are no packages in the official repo, and when I try building it myself it says glibc is out of date. I have the latest glibc from the official the repo, and am somewhat hesitant to go on updating it through other means. Are there any other packages that can help, or is there some way to get this working with an older version (we have tried back to cairo 1.8).
redhat 6 is clearly out of date. Of course it can be done bringing rh6 up to date with downloading and compiling your own 3.x kernel with all what's needed to meet the requirments for pycairo 1.10....
BUT it would be easier and nicer to install a more modern Linux Distribution which goes nicely with an old computer. Linux Mint 16 (Petra) provides a distro with replaxed requirments and window managers in i386 mode.
I don't see any meaning in trying to get up to date code on such an old os version running. Every replacement hardware you can get hold on ebay will do better than that.
cheers,
Christian
Related
I'm using Cygwin, and I am really impressed with the enhanced functionality of my Windows pc! However, I ran into a problem.
In order to setup Magento 2 on my Windows 8.1 Home pc, I need a virtual machine. Therefore I want to install libvirt, an open-source package that seems pretty old. However,on a Windows Home pc, it seems the only option. For libvirt to work, I need to setup an older version of libxml2: 2.6.0. Libvirt would not work with libxml2 2.7.0.
Installing libxml2 version 2.6.0 calls an old version of automake (1.6.3), which is unable to recognize my Windows file system.
I have tried changing aclocal.m4, replacing 'automake 1.6.3' to 'automake 1.15.1', but that didn't work:
AC_DEFUN([AM_AUTOMAKE_VERSION],[am__api_version="1.15.1"])
AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
[AM_AUTOMAKE_VERSION([1.15.1])])
Is there a way to install the old libxml2 version (2.6.0) using a new version of automake?
p.s.: I hope I made my issue clear. I apologize for newbee errors in my writing.
Redhat 5 has the required 2.6.18 kernel but not the latest glibc, g++ and certainly no clang. The binary distribution doesn't run, complaining about glibc version.
Has anyone made an attempt to back port to old Linux? I could imagine cobbling together a frankensystem with an old kernel but new compilers and try to compile against old glibc or statically compile in some of new glibc but it seems like a fraught course.
Just wondering if anyone has tried and can offer guidance?
I'm thinking there must be a distro setup to do such builds. Anaconda, for example, includes lots of new technologies but works fine on Redhat 5. I wonder how they build it?
Update: Once you get some newer compilers working on RHEL5 it's still not possible to build Rust because it depends on a working binary of itself to bootstrap. See: https://github.com/rust-lang/rust/issues/9545#issuecomment-54865031
Anaconda packages are built against CentOS 5 (which is equivalent to Redhat 5). The important thing is to compile against an old enough glibc, as it is strictly forward compatible (as you saw). The version of glibc is typically tied to the version of the distro, so your best bet is to make a VM with CentOS 5 and build on that.
The version of the compiler used is not as important, and in fact in some cases it is necessary to use a newer compiler than the old one that comes with the system to get things to work. I have gcc 4.8 built for CentOS 5 which you can get with conda (conda install -c asmeurer gcc).
I hit this very issue this weekend, because Skylight supports Linux 2.6.18, including CentOS 5.10, and we use Rust in our agent.
Alex Crichton of the Rust core team was kind enough to get this working again by using CentOS 5.10 boxes for the build, which uses glibc 2.5 and Linux 2.6.18.
While porting Qt project from windows to linux(ubuntu) i faced with the following issue:
on windows Qt version 4.8.1 is installed
on linux 4.6.3 in which some functionalities availiable in higer version 4.8.1 don`t yet implemented (ex. QUdpSocket::joinMultiCastGroup).
I see only one solution to this problem: upgrade Qt version on linux to 4.8.1.
How can I do this?
On linux I got installed libqt4-dev, qmake.
Solved: I changed repository from squeeze (stable) to wheezy(testing), in wheezy latest Qt version is 4.8.1, which is perfectly suits my needs.
Using package manager I found package libqt4-dev and selected it for update.
That is all, the whole process took 5 minutes.
Disadvantages:
- As I run Debian on Virtual Box after changing repository I had to reinstall guest additions
- wheezy is less stable than squeeze (I haven`t faced yet with stablilty problem)
I guess you can use Upgrade option in the Qt Creator.
Or you can download latest version from Download Qt, the cross-platform application framework
Or you could try to update using something like apt-get install(upgrade) libqt4-dev if you using Debian based system.
This depends on the distro you are using. If there are binary packages for your distro you can update through your package manager. Otherwise you have to download the source of your prefered Qt version and build it yourself.
I'm not sure if this will help in your situation, but you can download the Qt Online Installer at the following link:
https://www.qt.io/download-qt-installer
I have installed a bunch of qt packages - qt, qt-devel, qt4, qt4-devel, sip but can't get latest PyQt4 to compile.
I've pointed the configure script at my qt4lib as such
python configure.py -q /usr/lib64/qt4/bin/qmake --verbose
but getting errors like
DBus v1 does not seem to be installed.
cfgtest_QtHelp.cpp:1:25: error: qhelpengine.h: No such file or directory
sip: /mnt/hgfs/rnp_repos/PyQt-x11-gpl-4.8.1/sip/QtCore/qabstractitemmodel.sip:156: syntax error
Error: Unable to create the C++ code.
EDIT: Found out that SIP v4.11.2 is required for PyQt 4.8 but still can't make without errors. At least python configure.py finishes now.
Any tips?
Grab the PyQt4 SRPM from Fedora and rebuild using mock. You may need to look a few versions back for one that will compile against the version of Qt 4 in CentOS.
I've just successfully compiled PyQt 4.8 on Centos 5.5. I went down the route of building Qt4 from source - using qt-everywhere-opensource-src-4.7.1.tar.gz from Nokia.
Had to obtain various *-devel packages before Qt's ./configure would complete - see http://doc.qt.nokia.com/4.7/requirements-x11.html (don't worry about the version numbers being slightly lower than required).
Also I used Python 2.6 from the EPEL 5 repository (python26-devel). Just remember when building PyQt to run python26 configure.py (and not the default Python). I don't know if this will improve your mileage in building PyQt but we're porting an application from Windows which was already using 2.6 so this route was necessary for me.
Not going to post my entire .bash_history here (much trial and error!) but if you're trying this and get stuck please ask a question.
I'm attempting to build a binary package that can be run on multiple Linux distributions. It's currently built on Ubuntu 10.04, but it fails on Ubuntu 8.04 with the following error:
./test: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./test)
./test: /usr/lib/libstdc.so.6: version `GLIBC_2.11' not found (required by ./test)
What's the preferred way to solve this problem? Is there a way to install an old glibc on a new box and build against it, or do I have to build on an old distribution? And if I build against an old glibc, will it work on a new glibc?
Or, alternatively, are there just some handy compiler flags or packages I could install to solve the problem?
The best solution I've found is to install a virtual machine running Debian stable, and build on that. Debian stable is old enough that any packages built with it will run on any other Debian-based distribution like Ubuntu. You may have to work around non-critical bugs that have been fixed in later versions of various software but not backported to Debian stable.
If you really want to make sure it runs on every recent distribution, you might also consider statically linking against a libC you select. However you may then still run into problems if you use features that are only provided by newer kernels (newer system calls e.g.).