| Summary: | ssh no longer forwards Mathematica graphics | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Ed Friedman <ed> |
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | tibbs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-04-18 01:36:40 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | ||
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. |
From Bugzilla Helper: User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-27.8.0 i686) Description of problem: after ssh'ing to a machine, then running the mathematica command, mathematica does not launch. It does if working directly from the console without doing ssh. Version-Release number of selected component (if applicable): XFree86-4.3.0-2 How reproducible: Always Steps to Reproduce: 1.ssh to a machine which contains Mathematica 2.issue the command: mathematica 3. Actual Results: _X11TransSocketINETConnect: Can't get address for localhost XMathematica: can't open display localhost:10.0, exiting... Expected Results: Mathematica should have launched, as it has on every previous version of RedHat. Additional info: If you change the DISPLAY variable from localhost:10.0 to 127.0.0.1:10.0, then Mathematica will launch normally as it had under previous versions. When working directly on the console, instead of connecting via ssh, Mathematica launches normally. However, from the console, if you ssh to the machine you are on and then try mathematica, it fails.