[Techtalk] unresolved symbol?

[Almut Behrens]

On Mon, Nov 12, 2001 at 09:46:48AM +0000, Rachel Andrew wrote:
> Hi
> 
> I still have an unresolved problem with XFree86.
> 
> If I try to startx using XF86Config-4 it gets to the point of adding mouse 
> drivers and then crashes with a Signal 11 error. There are no other errors 
> apart from something to do with APM and it crashes while loading 
> peripherals in KDE2.2
> 
> I can startx (actually start KDE2.2) using the old XF86Config file but the 
> display is strange (funny lines across it) on going back to the shell I get 
> this error:
> 
> Symbol xf86InterpretEDID from module /usr/X11R6/lib/modules/libvbe.a is 
> unresolved

Hi Rachel,

as you seem to be planning to get a new machine, I'm not sure whether
you've already given up on getting this old system to work...
Yet, as a started writing this reply yesterday (but didn't get around
to completing it), I'll just post it, anyway.
Also, I'll admit up front, that I don't know whether it'll help much,
despite its length ;)  These kind of problems can be annoying at times...

First, a few notes on the "unresolved symbol" issue.  I have a little
script "huntsymb" that I normally use for these kind of things. Due to
its inherent ugliness, I was a bit hesitant to post it here up to now.
Anyway, I hope you'll bear with me, if I promise to rewrite it in
python one day ;)  Here it is:

#!/bin/sh

nmtool="objdump -t"
tmpfile=/tmp/huntsymb.$$

find . -type f -regex '.*\.\(a\|o\|so\)$' -exec sh -c \
  "$nmtool {} | grep -E ' \w*$1' >$tmpfile \
  && echo && echo {}: && cat $tmpfile ; \
  /bin/rm -f $tmpfile" \;

It will recurse through a directory tree hunting for a specific symbol
in all the library files it finds there. Used with a bit of intuition,
it can help to sort out various symbol-not-found problems.
Running this (i.e. "huntsymb xf86InterpretEDID") in the /usr/X11R6/lib
directory gives

./modules/drivers/nvidia_drv.o:
00000000         *UND*  00000000 xf86InterpretEDID

./modules/libddc.a:
00000000         *UND*  00000000 xf86InterpretEDID
00000000 g     F .text  000000bd xf86InterpretEDID

./modules/libvbe.a:
00000000         *UND*  00000000 xf86InterpretEDID

This shows that the function xf86InterpretEDID() is defined in libddc.a
(note the line with ".text" -- or more generally !="*UND*").

So you might try loading that module (i.e. load "ddc") in the "Modules"
section of your config file, to allow the symbol request from the VBE
lib to be resolved.
A bit of terminology as background info: DDC (Display Data Channel) is
a VESA (Video Electronics Standards Association -- I guess you knew
that one already) standard and communication protocol between the
monitor and the graphics card to enable the monitor to send infos about
supported screen resolutions, refresh rates and such. It sends an EDID
(Extended Display Identification Data) string that needs to be parsed
by whoever wants to use it. This is what the above routine
xf86InterpretEDID() does. The VBE (Vesa Bios Extensions) library
obviously makes use of that routine.

You mentioned that you're trying to get this to work on an older
machine, so chances are you might not have DDC support from the hardware
side. Still, you probably want to load the DDC module to get around the
unresolved symbol issue. Simply not loading the VBE module in the first
place doesn't seem to be an option, as I assume you need that when
using the vesa driver (not 100% sure, though).
If you experience problems with the DDC module while it's trying to
read out the EDID, you might try putting the "NoDDC" option in the
"Monitor" section. Don't be too surprised, though, if this doesn't
work -- it could be that the patch mentioned in the following note
from the XFree-changes-file hasn't yet found its way into the X you're
using:

XFree86 4.1.99.1 (20 August 2001)
 126. Patch to make VBE DDC honour the NoDDC option.
      Before this, NoDDC disabled only 2 of the 3 ways the server might
      ask the monitor for DDC infomation.
      (#4805 Andrew C Aitchison)

Also, you could try to fiddle with the option "IgnoreEDID", as
mentioned by one of the guys on debian-user.

Having said that, I must admit that I'm not too confident that this
will help you very much beyond the immediate problem of resolving the
unresolved symbol issue -- I'm not even sure if it does that... I'm
afraid that your X stuff will still be broken and KDE is likely not to
work. But you might give it a try, anyway.

Also, with respect to KDE on woody, I'm afraid I can't help you much,
because at home, where I'm running debian, I don't use KDE, and at
work, where I occasionally use KDE, we don't run debian -- so I'm a bit
out of luck trying to replicate the problem...

I guess you've already posted the problem to debian-kde, have you?

Having followed your thread on debian-user yesterday, I feel inclined
to add a few more general remarks. As you've correctly figured out,
your basic choices are to try to get the X-4.x running or to downgrade
to the old X-3.3.6.  Personally, I'd not yet give up on X-4.  Rather,
I'd try to do some more low-level debugging to get a clearer picture of
where and why things fail.

At the lowest level you'd probably want to go, my favorite tool
'strace' comes to mind. It might or might not help, depending on
whether the system calls made before X fails provide some hints that
you can make sense of. Often, you can already get a quite detailed
picture of what's going on just by looking at the files that are being
read... and, it usually doesn't cost much to try.  Just report back if
you want to go that route, and need further help.

However, before resorting to strace, I'd try to fiddle around a bit
with the XF86Config-4 file, in particular loading/unloading modules,
changing font paths, font servers, and stuff... If you're lucky, this
might already suffice to narrow down on the problem. Trial and error is
the name of the game. Once you know what's going on at a level somewhat
more detailed than "X+KDE-doesn't-come-up", you can search for more
specific help on google and friends...

Also, I'd definitely leave out KDE in the first round. You can take
care of that later on, once you've got X up and running.
For the moment, I'd use one of the lightweight window managers like
blackbox, etc. -- personally, I very much like the ultra-light pwm, but
that may not be everyone's choice :)
Also, X *can* be run without any desktop/window manager at all (for
debugging purposes).  Just don't forget to open up an xterm in the
startup file (~/.xsession in debian) -- without putting it in the
background with '&'. You'll then have a fixed rectangular area on the
X-screen where you can enter commands ;)  Typing 'exit' will get you
out of the xterm/shell and X.

OTOH, if you decide to downgrade to X-3.3.6 (or if it eventually turns
out that your hardware simply isn't supported in X-4), then get the
relevant old packages from stable/potato and install them. Previously,
you might want to get rid of the X-4 packages.
"dpkg --remove <package-names>" will do the job (or use --purge, if
you want to get rid of *everything* related to the package, including
config files). <package-names> will be more than one name, depending
on what you have installed. The metapackages x-window-system-core and
x-window-system will probably cover the right stuff.

To retrieve the old X packages, I wouldn't use apt-get, though it
probably can be done that way. (From the top of my head I couldn't
write down a recipe that's guaranteed to work -- I'd have to look that
up myself.)  Rather, I'd download the packages manually (e.g. via
debian's web interface) and use dkpg to install them, which is about
the same abstraction level as the rpm package manager.
Highlevel packaging systems are nice and convenient as long as things
run smoothly, but when something got stuck or a task it less usual,
it's sometimes plain easier to do the required things yourself.
With complex interdependencies, there are likely to be flaws at some
point in the automatic resolution mechanism. At least you'll risk being
the victim of some unforeseen, unwanted side effects. Taking care of
correcting these will usually take up more time than doing it yourself
in the first place...
Less magic, less trouble -- that's my humble opinion on the subject ;)
(btw, I'm not saying that debian's package system is broken in one way
or the other -- actually, I'd rather say that *it rocks*. It's just
a very general observation of mine...)

A good place to start downloading the old X packages is probably

  http://packages.debian.org/stable/x11/xfree86-common.html

This page does also provide pointers to what else you will need...
And, while downloading, use the time to consume the infos provided on
the webpages you encounter :)
(also, use Shift-click to download the .deb-packages you'll find on
the pages with the list of the available mirror sites -- otherwise,
the binary stuff might simply get displayed in the browsers window...)

Once you have the necessary packages on your harddisk, use
dpkg --install, possibly in combination with judicious use of some of
the --force-* options, to convince dpkg to put the stuff in its place.
(see "man dpkg" for the details -- it's reasonably comprehensible)

If that shouldn't work for some reason, you also always have the option
to unpack the stuff at an even lower level (as a last resort).
*.deb-packages are simple 'ar' archives (ar is a tool like tar that's
been around for decades on unix systems).
Just do an "ar x <package>.deb" in some temp directory and you'll find
the files "data.tar.gz" and "control.tar.gz". These are, as the names
imply, regular tar archives, that you can list, unpack and otherwise
manipulate as usual. The first one is the package's actual content,
while the latter one contains the 'control' files -- pre/post-install
pre/post-remove scripts, pkg-info, etc.  Simple and efficient... Okay,
I'll stop here before I get too enthusiastic ;)


In general, however, sticking with X-4, if somehow possible, is
probably going to be less trouble in the long run, if you want to run
more recent X packages -- just my intuition.

Good luck,

- Almut