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.
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 am trying to install a program on CentOS 6.10 and at the end of the installation, it gave an error saying that Glibc-2.14 is necessary. I upgraded the current Glibc and this time the error below occurred:
* These critical programs are missing or too old: gcc
* Check the INSTALL file for required versions.
I upgraded the gcc and tried to configure again. However, the same error persists. Hence I read the INSTALL file as it suggests, and I see this section:
You may also need to reconfigure GCC to work with the new library. The
easiest way to do that is to figure out the compiler switches to make
it work again (`-Wl,--dynamic-linker=/lib/ld-linux.so.2' should work
on GNU/Linux systems) and use them to recompile gcc.
So should I go to where gcc is built and do:
$ ./configure -Wl,--dynamic-linker=/lib/ld-linux.so.2 ?? Do I understand the instructions correctly? If so, then how will I be able to configure only gcc and not the other executable files as they are all in the same folder? (e.g gcc-5, git, idle, python, python-build.. etc) The directory is something like: home/linuxbrew/.linuxbrew/bin/gcc
I'm asking this because GNU compiler and GCC are fundamental in Linux system, and I'm not sure if those are the correct steps.
You are probably using a really old compiler (the one that comes with CentOS by default).
You need to install Red Hat Developer Toolset which provides up-to-date versions, see https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/ for more details:
Developer Toolset is designed for developers working on CentOS or Red Hat Enterprise Linux platform. It provides current versions of the GNU Compiler Collection, GNU Debugger, and other development, debugging, and performance monitoring tools.
im trying to solve this issue for a few days now and i cant find any solution.
I got myself an Atmega88A and i want to program it on fedora.
I tried to program C with gcc and that went well. But as i tried to include the avr/io.h, i always get the failure that it didnt found anything. I tried to get the new version of gcc, but that gives me an error too. Would it be enough to just download the avr/io.h library and implement it somewhere in my files? or is there any way to download this all together, including also all the other libraries that i need (e.g. util/delay.h)
You need to use a version of GCC that is specifically built to target AVR chips, you cannot just use the normal gcc executable for your system because it will produce the wrong kind of program. If you download a correctly-configured toolchain, then lines like #include <avr/io.h> should work automatically because the toolchain's default include search paths will be set up properly.
Many Linux distributions provide an avr-gcc package that you can just install with your package manager, including Fedora. You might have to install the avr-libc package to get the avr/io.h header.
If that doesn't work for some reason, you could try downloading Microchip's official AVR toolchain from this page:
http://www.microchip.com/avr-support/avr-and-arm-toolchains-(c-compilers)
What fixed this problem for me was this missing package: avr-gcc-c++. Running the command:
dnf install avr-gcc-c++
fixed it.
A C program compiled here runs fine on our Ubuntu servers. But when a somebody else tries to run it on their particular Linux server they get the following errors:
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./myprog-install)
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.7' not found (required by ./myprog-install)
Do I need to upgrade our glibc libraries and recompile? Or are they missing something on their server?
If I run apt-cache show libc6 my Ubuntu tells me the version is:
Package: libc6
Priority: required
Section: libs
Installed-Size: 9368
Maintainer: Ubuntu Core developers <ubuntu-devel-discuss#lists.ubuntu.com>
Original-Maintainer: GNU Libc Maintainers <debian-glibc#lists.debian.org>
Architecture: i386
Source: eglibc
Version: 2.11.1-0ubuntu7.10
If I look at http://packages.ubuntu.com/hardy/libc6 the current version appears to be 2.7-10ubuntu8.1.
I'm confused by the numbers. On the one hand 2.11-1-0 is a higher number than 2.7-11. On the other hand 7.10 is a lower number than 8.1.
Is it just a matter of me upgrading the C library package and recompiling do you think? Or is the other person's server missing some needed library there for compatibility?
You have built on glibc-2.11 system. You are trying to run on a system with glibc-2.3 or older. That's not going to work.
Is it just a matter of me upgrading the C library package
No: upgrading your glibc will only make things worse.
You may want to try solutions listed here.
Is this something we can reasonably request the other party to upgrade their system to support, rather than downgrade our compiler?
Usually the client will strongly resist requests to upgrade their system: it's working fine for them as is, and any upgrade can break other existing applications.
If you are planning to distribute binaries on Linux (as opposed to building them on the target system), then you need to learn how to make binaries that will run everywhere, or you need to state your requirements (minimum kernel and libc versions, etc.) and turn clients who can't meet these requirements away.
Update:
Why did they get two errors. Why didn't they just get one for GLIBC_2.11.1 which is apparently what I built with?
Symbol versioning doesn't work that way.
When a new symbol is introduced, it is marked with the current libc version, e.g. readdir64##GLIBC_2.2, posix_spawn##GLIBC_2.15, etc.
When you link a program that uses both of the above symbols, and try to run it on e.g. glibc-2.1 system, you would get two errors.
But if you link a program that doesn't use any of the above symbols, e.g.
int main() { return 0; }
then your program will just run without any errors.
Update 2:
they don't have to add both GLIBC_2.4 and GLIBC2.7 to their Linux system, do they?
No, they don't. The GLIBC_2.11 will have all the previous symbols in it. In fact, they couldn't install both glibc-2.4 and 2.7 even if they wanted to: it is quite difficult to have multiple versions installed at the same time, and impossible to have multiple versions installed in default location.
You've built it against a version of glibc that is too new. Build it against an older version of glibc, preferably the one that they are using.
you need to build on a system that uses same versions of libraries as you do. This is where docker and VM's are very convenient. There is probably a pre-made docker image for whatever version the customer has.
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.).