Ralf Wildenhues wrote:
So grab an old distro and build there, so that you link against
libstdc++.so.5. You're not only going to have trouble with libstdc++,
but also with newer libc's when trying to run a program on an older
system. Going the other way should be less painful: even current
systems typically have a libstdc++.so.5 for legacy code (like yours ;-)
(Although, come to think of it, I vaguely remember some issues with the
tls switch, concerning ctype; I don't know whether that applies any
more.)
A coworker suggested this same route this morning and we are planning to
try it (we already have the older machines available; that's how we
found the problem in the first place). We'll see if v6 is backwards
compatible with v5.
A completely static link is another option, given that you don't use any
of those modern features like loadable modules (dlopen), networking/NSS
(gethost* and others) and some other stuff (dunno about threads), as
those features need the dynamic libc at runtime (typically that should
be the same version, I think, for reproducible results).
We recently experimented with this idea (but building the compiler
without shared components). So we have a shared library plugin comprised
mostly of PIC code but with a few non-PIC components. It works unless
you have certain configuration options enabled, such as the secure
SELinux stuff.
--
-Mike Melanson
