[tlbuild] Testing cxx-runtime-hack -- V 1.1

[Peter Breitenlohner]

On Sun, 25 Jan 2009, Karl Berry wrote:

>    I'm still not convinced that including a deprecated header
>
> At first blush it looks like we can change the code to use
> #include <iostream>
>  using namespace std; /* or whatever is needed */
>
>    and relying on antiquated compilers is the best solution,

Let me try to address some separate aspects of this problem:

1. The KPSE_CXX_HACK autoconf macro certainly should test if either
 	#include <iostream>
 	using namespace std;
or
 	#include <iostream.h>
works (and the cxx-test program should accordingly use one or the other).

Looking through the TL source tree (svn), I found that
 	libs/graphite-engine
 	libs/teckit
 	libs/zlib/contrib	(not really used)
 	utils/lzma
unconditionally include <iostream>, whereas
 	libs/icu-xetex
uses '--with-iostream=[none|old|std|auto]', does some tests, and includes
either <iostream> or <iostrem.h> or nothing.  Might be used for debugging
only?

Just using <iostream> ought to be OK. Comments in libs/icu-xetex seem to
indicate that iostream.h was standardized Jun 1985 and <iostream> Nov 1997,
i.e., more that eleven years ago.

> It's still a good idea to use the oldest available compiler, though.  It
> is no panacea, but the resulting binaries are the most likely to run on
> the most systems.

2. For a private or distro build, '--with-cxx-runtime-hack' is not needed
and one can use whichever compiler and/or library versions.

3. For a TL binary build we would certainly want the resulting binaries to
run on the most systems.

That means in general not to use too recent compiler (e.g., gcc-3.3 or
gcc-3.4, not gcc-4.x) and C library (e.g., GNU libc-2.3, not libc-2.8)
versions.

There may obviously be problems building a program with new compilers and/or
libaries and trying to run it on an older system.  I just want to mention
that similar but maybe not so obvious problems may occur in the opposite
situation.

Recent we encountered this opposite problem. We wanted to install Maple on a
notebook running openSuSE 11.0 (X86-64) with libc-2.8.so.  There was,
however, a problem with the 32Bit version of maplelmg (FLex license
manager):
 	symbol errno, version GLIBC_2.0 not defined in libc.so.6
That may be a backwards incompatibility specific to the GNU C library, or be
due to the way openSuSE has compiled that library, or ...

Regards
Peter Breitenlohner <peb at mppmu.mpg.de>