xterm (actually all Xt clients) does not run

Bug #343574 reported by Dave Martin on 2009-03-16
Affects Status Importance Assigned to Milestone
libxt (Ubuntu)
Loïc Minier
Loïc Minier

Bug Description

Binary package hint: xterm

The traditional X clients do not run, probably due to a configuration issue, but I haven't managed to identify why. The applications print an error message and terminate, they do not crash, but are nonetheless unusable. These days, xterm is probably the only one many people are likely to care about, but the other programs do not run either:

$ xterm
xterm Xt error: Unresolved inheritance operation

$ xclock
Error: Unresolved inheritance operation

$ xfontsel
Error: Unresolved inheritance operation

$ export|grep DISPLAY
declare -x DISPLAY=":0"

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu jaunty (development branch)
Release: 9.04
Codename: jaunty

$ uname -a
Linux babbage 2.6.26-Patch-Jan20 #5 PREEMPT Tue Feb 17 19:20:53 UTC 2009 armv7l GNU/Linux

$ apt-cache policy xterm
  Installed: 241-1ubuntu1
  Candidate: 241-1ubuntu1
  Version table:
 *** 241-1ubuntu1 0
        500 http://arm-ports-ubuntu jaunty/main Packages
        100 /var/lib/dpkg/status

$ apt-cache policy libx11-6
  Installed: 2:
  Candidate: 2:
  Version table:
 *** 2: 0
        500 http://arm-ports-ubuntu jaunty/main Packages
        100 /var/lib/dpkg/status

$ apt-cache policy libxt6
  Installed: 1:1.0.5-3
  Candidate: 1:1.0.5-3
  Version table:
 *** 1:1.0.5-3 0
        500 http://arm-ports-ubuntu jaunty/main Packages
        100 /var/lib/dpkg/status

$ apt-cache policy xubuntu-desktop
  Installed: 2.81
  Candidate: 2.81
  Version table:
 *** 2.81 0
        500 http://arm-ports-ubuntu jaunty/universe Packages
        100 /var/lib/dpkg/status

Dave Martin (dave-martin-arm) wrote :

By the way, arm-ports-ubuntu is a mirror of ports.ubuntu.com. I have checked that this is up to date.
In any case, the problem described in this bug report has been happening for some time.

Loïc Minier (lool) wrote :

Hmm that's weird; could you check your .xsession-errors? Does this happen in an empty session running just xterm?

How to you start your session? GDM?

Dave Martin (dave-martin-arm) wrote :

This happens within GDM, in a raw X server, and also over remote X to a Cygwin/X server.

So it looks more like some issue with the X clients or Xt, rather than an X-server specific issue or an issue specific to running a particular kind of session...

Loïc Minier (lool) wrote :

Could you please attach your ~/.xsession-errors?

Dave Martin (dave-martin-arm) wrote :

I enabled IPv6 support in the kernel just to see whether there's a difference...
This removes the ICE errors from the log, but otherwise there no change. Oh well, it was a long shot :(

Dave Martin (dave-martin-arm) wrote :

Found a possibly relevant thread - sounds like there could be issues between some Xt functionality and shared libraries.
However, I don't understand the detail, and it's possible these issues do not apply to ELF platforms.


Jon Sevy (jsevy) wrote :

I have the same issue with Jaunty on the SheevaPlug platform (ARM little-endian) using the Xtightvnc VNC server and ICE window manager - xterm and many other X utilities fail to launch from the remote desktop and generate "Unresolved inheritance operation" errors in .xsession-errors log each time a launch is attempted:

xterm: generates
"xterm Xt error: Unresolved inheritance operation"

xclock: generates
"Error: Unresolved inheritance operation"

I upgraded libXt using apt-get upgrade libXt, but this had no effect on the problem.

Jon Sevy (jsevy) wrote :

On my platform, rebuilding libXt (on the target platform) seems to solve the problem; the X apps then launch without problem. So this suggests it's a problem with the libXt library.

Loïc Minier (lool) wrote :

I tried rebuilding libxt under babbage:
% LD_LIBRARY_PATH=$PWD/debian/tmp/usr/lib/ ldd /usr/bin/xterm
% LD_LIBRARY_PATH=$PWD/debian/tmp/usr/lib/ xterm
xterm Xt error: Unresolved inheritance operation

didn't help

But the fact it did for Jon is an interesting indication; Jon, what is your platform?

It could be a toolchain issue; perhaps we can compare config.log.

affects: xterm (Ubuntu) → libxt (Ubuntu)
Changed in libxt (Ubuntu):
assignee: nobody → canonical-mobile
importance: Undecided → High
milestone: none → ubuntu-9.04
status: New → Confirmed
Loïc Minier (lool) wrote :

The only bit of assembler I could find in libXt and which could be arch specific is:
asm (".data\n\
 .globl __XtInherit \n\
 __XtInherit: jmp *_y \n\
  _y: .long ___XtInherit \n\
    .text \n");
and it touches the "inheritance" logic apparently, but it's only for CYGWIN.

I tried rebuilding with -march=armv4t, but it didn't help either.

Loïc Minier (lool) wrote :

I also tried clearing LDFLAGS of -Wl,-Bsymbolic-functions; didn't help either.

Loïc Minier (lool) wrote :

Julien Cristau helpfully pointed out that xterm was setgid and hence LD_LIBRARY_PATH wouldn't work, and indeed my rebuilds of libxt with -march=armv4t and without LDFLAGS both work if I copy xterm to a new binary without the setgid flag; thanks!

I'll try a simple rebuild now.

Loïc Minier (lool) wrote :

Sorry, my testing was incorrect in the previous comment; ALL arches are affected, the issue is with LDFLAGS -Wl,-Bsymbolic-functions and a simple rebuild on amd64 shows the same bug.

Loïc Minier (lool) on 2009-04-11
Changed in libxt (Ubuntu Jaunty):
assignee: canonical-mobile → lool
Loïc Minier (lool) wrote :

I uploaded this debdiff to jaunty, pending approval. Fixes the issue on amd64 and armel for me.

Changed in libxt (Ubuntu Jaunty):
status: Confirmed → Fix Committed
Jon Sevy (jsevy) wrote :

- my platform is the SheevaPlug with Marvell PXA 168 "Sheeva" processor - though interestingly it lists as an ARM926 in the kernel log:
      CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053177
      Machine: Feroceon-KW
- gcc version is 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
- version of libXt built is 1.0.5 - and it was built _without_ applying patch libxt_1.0.5-3.diff

I'm attaching my config.log for comparison. Let me know if there's any other info you'd like.

Loïc Minier (lool) wrote :

Jon, thanks, it's not platform specific; probably it didn't happen in your rebuild because your dpkg-dev doesn't set LDFLAGS like the Ubuntu one.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libxt - 1:1.0.5-3ubuntu1

libxt (1:1.0.5-3ubuntu1) jaunty; urgency=low

  * Drop -Wl,-Bsymbolic-functions from LDFLAGS as it conflicts with the Xt
    inheritance mechanism; LP: #343574.

 -- Loic Minier <email address hidden> Sat, 11 Apr 2009 14:41:17 +0200

Changed in libxt (Ubuntu Jaunty):
status: Fix Committed → Fix Released
To post a comment you must log in.