Month: February 2004

I hate now knowing how things work. Especially things that I
rely on heavily as a hacker. But I love it when I get a chance
to finally figure out how the damn thing works and it turns out
to be beautifully simple.

This week I found that I had to debug a small part of libtool’s
behaviour. It had always worked for me before and I had assumed
it worked a certain way, but in this case it just wasn’t
working properly. I could feel myself breaking out in a cold
sweat. Don’t make me debug libtool! Please God, noooo…

But the clouds parted. And it was simple.

When you build an executable, and it links against a library
in the same module, you need some way to be able to run that
uninstalled executable with the uninstalled library. So,
libtool puts a script where you think your uninstalled
executable should be and here’s what it does

• When you run the script for the first time, it re-links
  your executable with --rpath $path-to-lib/.libs and
  places that executable in .libs/lt-myexec.
• That causes the linker to to put a DT_RPATH ELF
  attribute in the executable which tells the dynamic loader
  where to looks for libraries. (See the ld.so manpage)
• And finally, the script just runs the modified executable.

For example:

  $> ls -l .libs/*gdk-pixbuf-csource
  -rwxrwxr-x    1 markmc   markmc      51262 Feb 26 11:28 .libs/gdk-pixbuf-csource
  $> ./gdk-pixbuf-csource
  Usage: gdk-pixbuf-csource [options] [image]
  $> ls -l .libs/*gdk-pixbuf-csource
  -rwxrwxr-x    1 markmc   markmc      51262 Feb 26 11:28 .libs/gdk-pixbuf-csource
  -rwxrwxr-x    1 markmc   markmc      51294 Feb 28 15:48 .libs/lt-gdk-pixbuf-csource
  $> objdump -p .libs/gdk-pixbuf-csource | grep RPATH
  $> objdump -p .libs/lt-gdk-pixbuf-csource | grep RPATH
    RPATH       /gnome/head/cvs/gtk+/gdk-pixbuf/.libs:/gnome/head/INSTALL/lib
  $> ldd .libs/gdk-pixbuf-csource | grep gdk_pixbuf
          libgdk_pixbuf-2.0.so.0 => /gnome/head/INSTALL/lib/libgdk_pixbuf-2.0.so.0 (0x0087d000)
  $> ldd .libs/lt-gdk-pixbuf-csource | grep gdk_pixbuf
          libgdk_pixbuf-2.0.so.0 => /gnome/head/cvs/gtk+/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so.0 (0x004a0000)

Not exactly, earth shattering. But nice to know.

Its been a fun week completely focused on Fedora packaging and
bugzilla work. Had a nice wake up call on how huge a time sink
fixing non x86 builds can be. A day and a half debugging an ABI
mismatch on pcc breaking the gtk2 build! Sheesh.

Its nice to finish up a week with the feeling that you’ve got
a good handle on things, though.

I’ve been really taken by surprise at how my motivation has jumped
hugely with the move to Red Hat. I’m even enjoying things like bugzilla
work, packaging and release-team stuff these days. Clearly, this can’t
last. And I’ve got to get back hacking on things like Vino soon …

GNOME 2.6 looks like its pretty much on track. Things like the gtk+
schedule and the constant string freeze breakage has given the release
team the heebie jeebies somewhat, but after our irc meeting last night
I’m feeling pretty confident the release will come out without any huge
hitches.

Alex and I have been updating the GNOME packages in Fedora Core to the
latest GNOME Beta ones. Hopefully, by the time FC2 test2 goes into devel
freeze on Friday we’ll have most of the packages updated. A big priority
is to get the new file selector out to the Fedora testing masses, so
I’m going to update gtk+/atk/pango/glib to the latest today. Also going
to shove the little gnome-netstatus applet in too 🙂

So, I had a discussion with the RFB protocol maintainers at
RealVNC about getting the
new RFB security types – which I added in Vino for doing the
encryption thing – registered in the protocol. As far as I can
make out at this point:

• There are more security types registered than appear in
  the protocol specification.
• Security types 1-16 are reserved for “standard” security
  types.
• A security type becomes “standard” when it is added to the
  “reference implementation” … which just happens to be
  the same product RealVNC is trying to make money from.

I can’t make up my mind whether I care about this or whether
I should just leave sleeping dogs lie. My main worry is what
happens if we decide there are other additions we want to make
to the protocol. Oh well, cross that bridge when we come to it.
The RealVNC guys are friendly, so I don’t expect there would
actually be problems.

In the end, we agreed that I had to use different numbers to
identify the new security types and I had to modify the way
the new security type actually worked. End result – I’ve just
pushed a new version of Vino with incompatible changes in the
protocol.

I’ve just imported Vino into CVS. Its “Remote Desktop” functionality
for GNOME using VNC’s RFB
protocol which I wrote while at Sun.

Currently, the most notable bits over other VNC servers are:

• Support for encrypting the RFB protocol stream using SSL
• A dialog which prompts the user before allowing a remote user
  to connect
• Exports the local display, so you don’t have to start up a
  seperate VNC display
• Properly integrated into GNOME

More details

here.

The

TODO list includes:

• Use the new
  DAMAGE extension instead of polling the screen
• Write a GTK+ based client – the current client is a Java applet
  but you can use any other vncviewer without encryption
• Service discovery using DNS-SD and mDNS
• Better authentication schemes

A rather “interesting” day doing bugzilla work, disting and
pushing 2.5.4 tarballs and jhbuilding GNOME HEAD in parallel
over a 56k dialup line. I think I’ll be counting down the
minutes until the Eircom
fools manage to flick the magic DSL switch …

How on earth did I put up with this for an entire year in
New Zealand?