Bug 89111

This isn't an XFree86 bug.  It is a misconfiguration of something on your
system, or misunderstanding on your part.  ssh X11 forwarding works perfectly
in Red Hat Linux 9, it's used every day extensively both inside Red Hat as
the primary method of running remote X applications, as well as outside
Red Hat.

For technical support, try one of our mailing lists as bugzilla isn't a
tech support forum.  Bug reports only here please.

Thanks.

Well, considering that RedHat 9 has a nonfunctional /usr/lib/libglut.so.3.7, and
is missing the /usr/lib/libtcl.so.0 and /usr/lib/libtk.so.0 links, I suspect
that the problem with Mathematica is due to either some other nonfunctional
library or some other missing library link (which only seem to be a problem in
RedHat 9).  The real question is what has changed in RedHat 9 that breaks X
applications such as Mathematica and RealPlayer?

Ed Friedman

Red Hat Linux 9 does *not* break realplayer.  Realplayer _is_ broken itself,
because it makes false assumptions about how things work.  Those assumptions
are based on undefined behaviour, which means as long as the undefined
behaviour just so happens to work the way that your code expects them to,
then your application might also work.  As soon as those undefined behaviours
change however, then your application is likely to break.

"Undefined" means that something is undefined, and it may change at any point
in time completely randomly, and by definition it is free to do so.  If
something undefined was guaranteed to have the same behaviour always and never
change - then it would not be "undefined", but rather it would be "defined" and
documented behaviour.

Start putting the blame in the right place, and you might find a solution.

I have no idea about Mathematica.  Possibly it's a similar problem.  If
Mathematica is a threaded application, then there is a high likelyhood that
it uses threads in a broken way and relied on undefined behaviour as well.

Red Hat Linux now uses NPTL, which is a Red Hat developed posix threads
implementation which is more standards compliant than prior Linux thread
implementations.  Applications which make bad assumptions might break, if
they do, it is not our fault, it is the fault of the people who wrote
the broken code.

Since we care about standards, and moving forward, we set our goals at doing
so, and we're not held back by broken applications.  We do however provide
backwards compatibility mechanisms so that old broken applications can
continue to run.  Our release notes indicate some of the mechanisms that
you can use to get broken applications such as Realplayer to work.

Wether or not Mathematica is one of these broken applications or not, I 
don't know.  I do know however that none of your rantings above have
ANYTHING whatsoever to do with XFree86, so please discontinue.

I know this is closed, but I'm investigating a closely related problem and
thought I would add some information for anyone else who searches on "mathematica".

The basic issue is that Mathematica cannot call any resolver functions properly
under Red Hat 9.  Just running the text-mode interface will fail if startup
requires resolving hostnames or even a protocol number (getprotobyname).  Thus
if you use a network license manager, Mathematica cannot contact it.  Using a
hostname in mathpass and running with '-lmverbose' you get: 

Talk to server 'license.server.host' on port 16286 ...Cannot get
"license.server.host" host entry.

Running nscd in debug mode shows plainly that the call succeeds, and strace
shows that the results come back properly.  If you replace the hostname with an
IP address, you get:

Talk to server '10.1.1.1' on port 16286 ...Cannot get "tcp" protocol entry.

The same Mathematica version (4.2) runs on Red Hat 8.0, even with the errata
glibc.  Mathematica version 4.0 runs fine on all Red Hat versions I have access
to (even 9).  No word on Mathematica 5.0 yet.

I suspect that TLS is the cuplrit, but I cannot figure out how to disable it.  I
know about LD_ASSUME_KERNEL but setting it to both 2.4.1 and 2.2.5 has no
effect.  MathKernel is statically linked so I'm not sure if it would help
anyway.  An strace of the program still shows it opening /lib/tls/libc.so.6 just
before calling into the resolver.  Renaming /lib/tls out of the way (and running
ldconfig) just results in a segfault; strace produces this rather bit:

--- SIGSEGV (Segmentation fault) @ 0 (0) ---

So this is definitely not an XFree bug.  It may be properly considered as a
glibc issue; they probably wouldn't call it a bug.

Unfortunately this is holding up a Red Hat 9 rollout.  Hopefully Wolfram will
respond; if they do, I will incorporate their response into this bug.

The resolution from Wolfram is to follow the instructions at:

http://support.wolfram.com/mathematica/systems/linux/intel/dynamic.html

which detail the installation of dynamically linked libraries.  This seems to
work, but I do see the message:

Incorrectly built binary which accesses errno, h_errno or _res directly. Needs
to be fixed.

I've no idea how big a problem this really is; so far everything seems to be OK.