When trying to run Light table on my CentOS 6.5 I get this message:
/lib64/libc.so.6: version `GLIBC_2.15' not found
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found
I dont want to install a newer glibc from source since I'm afraid to break other systems using the older version. Any advice on how to proceed?
I'm getting the same problem and, according to another answer there's no way around it. LightTable was compiled with more recent libraries that CentOS doesn't ship with. The alternative seems to build node-webkit from source (as stated on their GitHub page) but I haven't tried that yet. If I find a better solution I will update my reply.
Compiling fixed it for me.
They seem to have compiled it with an older version of gligc now.
Related
I have installed the following
C:\MinGW
C:\msys
C:\GTK
But python searching for the files in site packages and throwing the error as:
OSError: cannot load library libcairo.so.2: error 0x7e. Additionally, ctypes.util.find_library() did not manage to locate a library
This issue happening in installation of weasyprint packages.
Installing GTK+ didn't work for me.
I solved this problem using UniConverter2.0.
My environments is
Python 3.7
Windows 10 x64
Install uniconvertor-2.0rc4-win64_headless.msi,
Find the "dll" sub-directory under the UniConverter installation path.(In my case, C:\Program Files\UniConvertor-2.0rc4\dlls)
Add this "dll" path to the system path.
Close VSCode and reopen the project.
Try to run your code again.
Enjoy!
In my experience with this issue Windows 10 (64-bit) with Python 3.5.1, it can be either due to duplicate libraries in other directories seen by PATH that don't work or the libraries that you installed just aren't compatible with your OS/Python bit version.
I suggest installing an older version of GTK+ (I used 3.10.4) using the links provided in the WeasyPrint documentation instead and see if the error persists. I had the issue on a newer build of GTK+. The version of GTK+ installed with MSYS2 gave the same error.
Edit: I found the post where I found the previous version of GTK that I was using but it gave an annoying warning about the cairo version being unstable:
See this post.
Edit 2: To get rid of the cairo version stability warnings, I managed to get a newer version of Cairo using the GTK3-runtime-3.22.8 (Link to git downloads as per WeasyPrint docs)
Remember to uninstall all current GTK+ implementations first. You might get a warning saying that the version of cairo can cause issues but I haven't been able to locate a newer version of cairo that works in windows, let me know if you find one.
I'm new to REDHAWK and I noticed that with REDHAWK 1.10 that GNUHAWK seems to be all but gone. Does anyone know any information about what happened to the it. It looks like it could be a really useful tool. And if it's only available on older versions I could you point me to a guide I haven't been able to find an installation guide for 1.9 either...
You can clone GNUHAWK from here and add it to your system: https://github.com/RedhawkSDR/integration-gnuhawk
The REDHAWK 1.9 distribution includes RPMs for GnuHawk. You can install them as you would any other RPM file. To find the RPM you need, go to http://sourceforge.net/projects/redhawksdr/files/redhawk/ and drill down for REDAWK 1.9.0 and your desired platform.
You may also want to check out the build instructions here: https://github.com/RedhawkSDR/integration-gnuhawk/tree/develop-1.9
The mysql++ package that comes from tangentsoft, is version 3.1.0 and I am having trouble building on my linux system. To get it to configure I had to specify the with the flag
./configure --with-mysql-lib=/usr/lib/i386-linux-gnu/
Otherwise there was a problem with it finding the mysqlclient library. Now unfortunately it wont make, the error I get is ./lib/refcounted.h:258:2: error: ‘size_t’ does not name a type, after I type make and before I type make install.
Has anyone had the same problem with compiling it, and did you find a solution?
Any help it solving this problem is appreciated.
There are a few #include fixes in the svn version of MySQL++ that haven't yet been included in a release version. They're necessary on modern OSes like yours, which include recent GCCs and libstdc++'s.
Don't be nervous about using the svn version in production. It's quite stable at the moment. My reasons for not releasing it as-is aren't related to stability.
I was trying to install jdk1.6 onto my Ubuntu 10.04.
However, It looks like jdk1.6 is no longer available in Ubuntu repository(at least, i havent found it yet).
In my case, I need to install jdk1.6 as my java version instead of openjdk.
Could anyone tell me if it still could be found in anywhere?
Thanks.
I suggest installing it manually. Use the following link and use update-alternatives. The instructions are for 1.7 but they work for 1.6. Just get it from sun's site.
https://askubuntu.com/questions/55848/how-do-i-install-oracle-java-jdk-7
You can download JDK from java.sun.com and install it yourself. The reason its not included because it needs you to accept their license agreement.
HTH.
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.).