I don't mean the version(s) provided by the various distributions but the binary from the official website.
I have an old VM running 32bit OpenSUSE 12.1 that is configured for a project I'm working on at work. I need to install WebKitGTK. The problem is that the cmake in the repositories is ancient 2.x, while WebKitGTK at least 3.6 (or similar). So I went to the official website and (my fault) without looking too much into it downloaded the 3.10 installation for Linux.
Upon executing the binary that was installed I got the error that the file could not be run. I checked the execution rights and it was fine. Then it struck me...I ran file cmake and got 64 instead of the required 32bit.
I went back to the website and all I could find were 32bit versions for Windows but none for Linux.
I can build it from source but just out of curiousity would like to know if support has been dropped. I was unable to find any information so far.
32-bit support for CMake hasn't been dropped. They just don't provide binaries for it on their website as of CMake 3.7.0
Related
i trying to create a appimage for my Linux system. Using qt-creator i have completed the programing and ran the app successfully . but when i am trying to make it appimage using linuxdeployQt i am facing some errors
linuxdeployqt 5 (commit 37631e5), build 631 built on 2019-01-25 22:47:58 UTC ERROR:
The host system is too new.
Please run on a system with a glibc version no newer than what comes with the oldest still-
supported mainstream distribution, which currently is glibc 2.20.
This is so that the resulting bundle will work on most still-supported Linux distributions.
For more information, please see
https://github.com/probonopd/linuxdeployqt/issues/340
i don't know what this issue is. when i visit the website, it is not clear also. So anyone familiar with this kind please put your help here.
It means that your glibc is too new.
That's correct, to work around this issue while using linuxdeployqt you have to choose as build environment an older system such as Centos 6 or Ubuntu 14.04.
As an alternative, you can use appimage-builder which allows producing AppImages on newer systems.
It means that your glibc is too new. I think it is supported glibc version comes with Ubuntu 14.04 as it is mentioned in herr https://github.com/probonopd/linuxdeployqt/issues/340. I have faced the same problem and still struggling to solve this issue.
I can get Snap7 working on Linux but not on Windows using Pycharm. I get:
WindowsError: [Error 193] %1 is not a valid Win32 application.
I have tried Python 32 and 64 bit version using all combinations of the snap7.dll, the ones in the archives Win32 and Win64. I'm using Windows7 64-bit Professional. What's going on?
I have been working on a Linux system also with Snap7 for the past few months, to come over to Windows to also receive this issue. Only reason I haven't noticed this sooner is because I have been using the ClientDemo in the Snap7 Package.
I have tried the following:
Going back to older versions of Python (e.g. 2.7 where the documentation says its compatible)
un-installing and installing the packages (Both Python and Snap7)
There is only one thing I can clearly think of, and that it is the OS. Not sure if its all flavors of Windows 7 however. The documentation for the installation also states:
"Python-snap7 is developer for snap7 1.1.0 and Python2.7. It is tested on Windows (8.1 64 bit) and Linux, but it may work on other operating systems. Python 2.6 and Python 3+ may work, but are not fully tested yet."
Link: https://python-snap7.readthedocs.io/en/latest/introduction.html
So perhaps by chance, we are just unfortunate and that it does not work with this specific OS?
I've downloaded the latest version of CefGlue as well as the corresponding CEF binaries. I can get the demo examples to run fine in Windows, but the Linux GtkSharp demo does not run. It compiles fine under MonoDevelop on my Linux box but throws a DllNotFoundException: libcef
I've put the libcef.so in the executable directory as well as running ldconfig in the CEF release directory.
I'm new to Linux, so there's probably something simple and obvious that I'm missing.
The answers on this Bitbucket issue explain how the library path resolution can be fixed.
Unfortunately, this Bitcuket issue goes on to explain that Linux support is broken and the maintainer Dmitry says that he doesn't have the resources to support linux.
I am working on a machine with Scientific Linux 6.1 for which I do not have root access, and one of the program I need to run requires a particular library version that is contained in gcc from version 4.8.1 on.
Unfortunately the last version installed on the system is 4.7.2, so I was looking for some binaries in order to compile it myself in a local folder. My search for binaries was not successful and the main suggestion I have found googling was to install the devtoolset, that I can't install as I do not have root access.
Can someone point me to a place where I can find binaries?
Can I install an older version of gcc/g++ (4.1.3) on the latest Ubuntu (which comes with 4.4.3) and use it to compile a .so which should run on CentOS? The binary compiled with the Ubuntu version of gcc fails to load on CentOS because of missing imports (GLIB_2_11, ...). I need C++ (including exceptions), so I can't just statically link against glibc, which I already tried.
Can I install the older gcc without removing the newer one? How do I go about the libs required by the older gcc?
I'm currently developing code in CentOS, but it's such a pain to use. I really want to move to an Ubuntu desktop.
g++-4.1 is available for Ubuntu; just run apt-get install g++-4.1 then run g++-4.1 instead of g++. However, simply using an older compiler may not fix all of your library issues.
Like Joachim Sauer said, your best bet is to do your development on Ubuntu then do the final compilation on CentOS.
Even though you're using C++, static linking should still be an option. (However, you're much better off compiling on CentOS and using dynamic linking.)
Edit: A virtual machine is the most straightforward way to build on CentOS, but if you want to avoid the memory and CPU overhead of running a VM and don't care about differences between Ubuntu's and CentOS's kernel, then you can create a subdirectory containing a CentOS or Fedora filesystem and chroot do that to do your builds. This blog posting has details.