Additional info, in case it helps to track down an obvious error:

The failure is always in the same place: doing a stat.  The ltrace shows

[pid 4803] fopen("/net/opt/applix/axdata/fontmetri"..., "r") = 0x084c3938
[pid 4803] fileno(0x084c3938)                     = 11
[pid 4803] _fxstat(1, 11, 0xbfffd17c, 0x082e0030, 21 <unfinished ...>
[pid 4803] --- SIGSEGV (Segmentation fault) ---

and the corresponding strace gives

[pid  4852]
open("/net/opt/applix/axdata/fontmetrics/gallium/fs/aplxfont/fonts.dir",
O_RDONLY) = 11
[pid  4852] --- SIGSEGV (Segmentation fault) ---

so the _fxstat is failing before it gets as far as the system call.  Using
glibc-2.1.94-3, the ltrace shows

[pid 4833] fopen("/net/opt/applix/axdata/fontmetri"..., "r") = 0x084c3938
[pid 4833] fileno(0x084c3938)                     = 11
[pid 4833] _fxstat(1, 11, 0xbfffd17c, 0x082e0030, 21) = 0

at the same location --- the arguments are precisely the same but the call
fails.

Can you please run gdb on the generated core?
It looks like __fxstat with vers == _STAT_VER_KERNEL which does just:
  if (vers == _STAT_VER_KERNEL)
    return INLINE_SYSCALL (fstat, 2, fd, CHECK_1 ((struct kernel_stat *) buf));
so I'm interested if you could find out crashing $pc and disas that routine
to make sure we're looking at the same code.

There's no core file --- axmain has set up a sig11 handler.

However, sending the process a SIGSTOP lets me attach gdb to it, and I can get
as far as the segv that way.  I see:

>>>>
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0 in ?? ()
(gdb) bt
#0  0x0 in ?? ()
#1  0x83082f4 in fstat ()
#2  0x8307510 in FontFileReadDirectory ()
#3  0x82e0046 in FontFileInitFPE ()
[ lots more application stack frames ]
>>>>

which is calling fstat from deep in font server country.  Dumping the args list
for frame 1 on the stack shows the args (0x0000000b, 0x08307510), so we look
like we are in the right territory.  The fstat disassembly begins
(gdb) disas 0x83082f4
Dump of assembler code for function fstat:
0x83082e0 <fstat>:	push   %ebp
0x83082e1 <fstat+1>:	mov    %esp,%ebp
0x83082e3 <fstat+3>:	push   %esi
0x83082e4 <fstat+4>:	push   %ebx
0x83082e5 <fstat+5>:	mov    0x8(%ebp),%ebx
0x83082e8 <fstat+8>:	mov    0xc(%ebp),%esi
0x83082eb <fstat+11>:	push   %esi
0x83082ec <fstat+12>:	push   %ebx
0x83082ed <fstat+13>:	push   $0x1
0x83082ef <fstat+15>:	call   0x80918b4 <_fxstat>
0x83082f4 <fstat+20>:	add    $0xc,%esp

so we're definitely seeing the _fxstat entry point here.  _fxstat itself is

(gdb) disas 0x80918b4
Dump of assembler code for function _fxstat:
0x80918b4 <_fxstat>:	jmp    *0x8424b08
0x80918ba <_fxstat+6>:	push   $0x8b8
0x80918bf <_fxstat+11>:	jmp    0x8090734 <_init+52>

but

(gdb) x 0x8424b08
0x8424b08 <__DTOR_END__+1132>:	0x00000000
(gdb) 

so no wonder we have jumped into hyperspace.  The memory around 0x8424b08 all
looks valid so this isn't a complete memory wipe we're looking at.  Running from
scratch with a breakpoint at main shows that the jump vector at 0x8424b08 points
to <_fxstat+6> initially, so it looks like we're doing a fixup to NULL at some
point.

Btw, according to the lstat, this is the process's first invocation of  _fxstat,
although there were several prior successful _xstat calls.

_fxstat (and likewise _xstat and _lxstat) are not exported from glibc since
glibc 2.1, so I wonder why it worked with earlier glibc's.
Is Applix glibc 2.0 application, right? Even then, it is pretty strange,
because /usr/lib/libc_nonshared.a in RH5.2 referenced __fxstat (that symbol
is exported from glibc), so probably Applix just used its own magic fstat or
whatever (because libc_nonshared used vers 3 (aka _STAT_VER_LINUX) while
Applix uses vers 1 (aka _STAT_VER_KERNEL).
Can you perhaps run it both with glibc 2.2 and glibc-2.1.94-3 with
LD_DEBUG=all set in environment?

glibc-2.1.94-3:

05099:	symbol=_fxstat;  lookup in file=/net/opt/applix/axdata/axmain
05099:	symbol=_fxstat;  lookup in file=/lib/libNoVersion.so.1
05099:	binding file /net/opt/applix/axdata/axmain to /lib/libNoVersion.so.1:
normal symbol `_fxstat'

glibc-2.2-5:

05071:	symbol=_fxstat;  lookup in file=/net/opt/applix/axdata/axmain
05071:	symbol=_fxstat;  lookup in file=/usr/X11R6.local/lib/libX11.so.6
05071:	symbol=_fxstat;  lookup in file=/lib/libdl.so.2
05071:	symbol=_fxstat;  lookup in file=/lib/libcrypt.so.1
05071:	symbol=_fxstat;  lookup in file=/usr/lib/libstdc++.so.2.8
05071:	symbol=_fxstat;  lookup in file=/lib/libm.so.6
05071:	symbol=_fxstat;  lookup in file=/lib/libc.so.6
05071:	symbol=_fxstat;  lookup in file=/lib/ld-linux.so.2
<then continues with next symbol --- no bind happens>

So we are finding _fxstat in /lib/libNoVersion.so.1 in glibc-2.1.94, but we
aren't even looking in that library with glibc-2.2.  _fxstat _is_ in the
libNoVersion for glibc-2.2-5, but ld.so isn't looking there.  I can attach the
full debug file from 2.2 if you want: it's only 140k compressed.

I'll look at the libNoVersion loading code over the weekend.
Thanks for tracing this down.

Do you want the LD_DEBUG log?

No, I think I've nailed it down (_dl_map_object interface is changing all
the time), will see after glibc-2.2-6 build (after I nail down one more issue).

ETA?

Most probably tomorrow will push it through the build system,
I spent today some time fixing other glibc issues and with
the exception of one unreproduceable report all are fixed.

Fixed in glibc-2.2-9 errata.