libstdc++.so.6: version `GLIBCXX_3.4.9' not found
mathieu
I am looking for documentation which would explain how to use older
glibc symbol. Right now, when I compile binaries on my linux debian
system (using g++ 4.2) people running the exe on there older linux
system are getting:
libstdc++.so.6: version `GLIBCXX_3.4.9' not found
This look like an extremly simple problem, but I cannot find
anything on google, as I am missing the 'right' keyword to search for
Thanks !
-Mathieu
Ps: most post I found on internet are pretty much saying: 'use a newer
glibc', while I am looking for the opposite :)
Paul Pluzhnikov
> I am looking for documentation which would explain how to use older
> glibc symbol. Right now, when I compile binaries on my linux debian
> system (using g++ 4.2) people running the exe on there older linux
> system are getting:
>
> libstdc++.so.6: version `GLIBCXX_3.4.9' not found
In general, UNIX systems do not support "develop on newer release;
run on older release" model. Only the inverse is supported (i.e. old
binaries still run on newer systems).
> This look like an extremly simple problem, but I cannot find
> anything on google, as I am missing the 'right' keyword to search for
It's not very simple, but there are several possible solutions.
See this message for some of them:
http://groups.google.com/group/gnu.g++.help/msg/32c0df4f11ff018a
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
mathieu
On May 3, 6:23 pm, Paul Pluzhnikov <ppluzhnikov-...@gmail.com> wrote:
> mathieu <mathieu.malate...@gmail.com> writes:
> > I am looking for documentation which would explain how to use older
> > glibc symbol. Right now, when I compile binaries on my linux debian
> > system (using g++ 4.2) people running the exe on there older linux
> > system are getting:
>
> > libstdc++.so.6: version `GLIBCXX_3.4.9' not found
>
> In general, UNIX systems do not support "develop on newer release;
> run on older release" model. Only the inverse is supported (i.e. old
> binaries still run on newer systems).
ok.
> > This look like an extremly simple problem, but I cannot find
> > anything on google, as I am missing the 'right' keyword to search for
>
> It's not very simple, but there are several possible solutions.
> See this message for some of them:http://groups.google.com/group/gnu.g++.help/msg/32c0df4f11ff018a
Thanks ! So you suggested basically 3 solutions:
> 1. Build on the oldest release of glibc you plan to support (we
> build on ancient RedHat 6.2 with glibc-2.1, and it runs *everywhere*).
> 2. Use Autopackage (http://autopackage.org/apbuild-apgcc.php)
> 3. Use x86-glibc-2.4 -> x86-glibc-2.3.2 cross-gcc (see http://www.kegel.com/crosstool).
I am running a linux debian stable, let say I install g++3.4, if I
build an executable using this particular I should be garantee that
the binary use a quite old GLIBC API, right ? Since this is not listed
in your solution, I am guessing there is a good reason, but I do not
see what's wrong here...
You seems to have a quite elaborate solution since you can run
'everywhere' in my case, since my project is written in C++, I will
only be able to support system that understand ABI version=2 of g++.
So I thought using the earliest possible implementation of ABI
version=2 in g++ 3.4 should solve my issue.
As a side note, since solution #1 seems to be used internally in
solution #2 (apgc is shipped with some kind of old glibc), do you have
any further documentation on how to do that. apgcc is not part of
debian...
I might eventually try solution #3 as support for cross compilation
seems to be a lot easier when using cmake (http://cmake.org), I'll try
to reproduce what was done there.
Thanks again for your help
-Mathieu
Paul Pluzhnikov
> I am running a linux debian stable, let say I install g++3.4, if I
> build an executable using this particular I should be garantee that
> the binary use a quite old GLIBC API, right ?
There are 2 separate issues:
1. GLIBC API
2. GLIBCXX API
The article I referred you to deals only with "issue 1".
So far, your users have only hit the "issue 2".
I am guessing that as soon as you fix it (by using g++-3.4 to
build), your users will start hitting "issue 1" (which can *not*
solved by installing any version of gcc).
> As a side note, since solution #1 seems to be used internally in
> solution #2 (apgc is shipped with some kind of old glibc)
Apgcc did not include any old version of glibc last I looked,
only cross-compiler does that.
Solution #1 is the simplest in terms of what one has to do, provided
one has an extra machine laying around [1], and is conceptually
simplest to understand.
> do you have
> any further documentation on how to do that. apgcc is not part of
> debian...
Huh?
Couldn't you just follow instructions on the autopackage pages?
Probably start here: http://autopackage.org/download-tools.html
> I might eventually try solution #3 as support for cross compilation
> seems to be a lot easier when using cmake (http://cmake.org), I'll try
> to reproduce what was done there.
It is just as trivial to use cross-compiler from "regular" make:
instead of "CXX = g++" or "CXX = /usr/local/gcc-3.4/bin/g++",
you just do
"CXX = /usr/crosstool/gcc-3.4-glibc-2.2/i386-.../bin/i386-..g++"
Cheers,
[1] Our ancient RedHat-6.2 machine died recently. So we now build
on a VMWare RedHat-6.2 image, running "inside" Fedora 7. Despite
virtualization overhead, this is still 2 times faster than what
the old hardware could do.
Miles Bader
> Couldn't you just follow instructions on the autopackage pages?
> Probably start here: http://autopackage.org/download-tools.html
Autopackage doesn't seem to behave very nicely on debian systems
(e.g. it writes over stuff in /usr, even if one has told it to install
in /usr/local).
I'd be kind of nervous to install autopackage'd stuff generally.
-Miles
--
Advice, n. The smallest current coin.
Paul Pluzhnikov
> Autopackage doesn't seem to behave very nicely on debian systems
> (e.g. it writes over stuff in /usr, even if one has told it to install
> in /usr/local).
I see.
However, apbuild (which, I believe, is all that's required to solve
OP's problem) can be installed anywhere.
Cheers,