Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

I installed XChat on an Arch Linux system. Every time I run it, I get the following error message:

Python interface loaded
Perl interface loaded
AutoLoad failed for: /usr/lib/xchat/plugins/ cannot open shared object file: No such file or directory

So while the plugins for Python and Perl are loaded correctly, the Tcl plugin is not. In fact, python2 and perl packages are installed on my system, while tcl package is not. Installing tcl fixes the problem.

Before installing tcl, I get:

ldd /usr/lib/xchat/plugins/ | grep tcl => not found

After installing tcl, I get:

ldd /usr/lib/xchat/plugins/ | grep tcl => /usr/lib/ (0x00007fceba533000)

It seems that tcl is not a required dependency of xchat, but an optional one:

pacman -Qi xchat
Optional Deps  : enchant: for spell checking support
                 tcl: for tcl plugin
                 python2: for python plugin

Why is this the case? That is, why the tcl package is not installed along with xchat by default? Isn't xchat broken without tcl?

I filed a bug more than two years ago, but I never really understood why things are this way in Arch Linux land. Please notice that while this bug is old, I'm only running this distribution on a daily basis since a couple of months, so I'm an Arch Linux newbie.

I could have asked on Arch Linux forums or mailing lists, but I'm quite interested in knowing the point of view of other Linux distributions users. Arch Linux users are also welcome, of course.


  1. The error message I get when running XChat without tcl installed is clearly visible in the GUI, in the same place where messages are displayed.
  2. My question can also be reworded in the following way: why XChat, despite having clearly been built with --enable-tcl or equivalent passed to the configure script, can be installed without a mandatory dependency on the tcl package? If one don't want tcl, he should use --disable-tcl.

EDIT. I opened a thread on the Arch Linux forum, but I didn't get a satisfying answer. So I checked Debian and Gentoo, and it seems they don't have this problem.

share|improve this question
Is it really broken though? Does that error prevent it from starting or is it just noise? – Mat Sep 23 '12 at 9:41
I forgot to say that despite that error message XChat is working great anyway. I don't think I need plugins at all. – Francesco Turco Sep 23 '12 at 9:44
So I don't understand your question at all. Clearly TCL isn't a required dependency. – Mat Sep 23 '12 at 9:45
I may be wrong, but software should be installed in such a way that the user should not be alarmed by error messages, even if they are relatively innocuous. – Francesco Turco Sep 23 '12 at 9:57
Isn't that message visible only when you launch xchat via the command line? Wouldn't most users run it from a menu/icon thing? – Mat Sep 23 '12 at 9:58

2 Answers 2

up vote 7 down vote accepted

It's mostly a matter of complexity and how people choose to invest their time.

If you wanted an XChat binary package that doesn't show any warnings/errors related to missing libraries for plugins, you have essentially two choices:

  • only include/configure "vital" plugins, and add hard dependencies for what those things require
  • include each and every plugin available, and add hard dependencies for what those things require

The first option leaves you with an XChat package that doesn't have a lot of features at all. You'd then need an xchat-perl package, an xchat-tcl one, an xchat-gtk, ... All these packages need to be maintained, patched, upgraded, etc. That's a lot of work.

The second option gives you a bloated XChat package that pulls in lots of other stuff, most of which won't be used at all by the average user. Not really satisfactory for distributions like Arch.

You can try to find a sweet spot between these two, but chances are you won't find the perfect fit.

What the Arch devs apparently did with the package is ship a commonly used plugin without forcing the user to install the dependency. That (leaving out the error message for now) is actually pretty nice for the user: those who don't want/need the TCL don't have to install it to get XChat. Those who do can just install TCL and the XChat TCL plugin will just work.
So that's a nice compromise. If you, in the future, would like to use TCL to script your XChat, all you'll have to do is install TCL - you won't have to worry about updating XChat or installing yet another package.

As for the error message, it's purely cosmetic. Could it be fixed? Probably.
Could it be fixed easily in a way that still lets the plugin start working right after installing TCL (without additional packages or configuration changes, reverse dependency checks, ...): that's not all that certain.
Should the Arch devs/maintainers spend time on trying to remove this cosmetic issue? That's debatable. Giving that the software works, this should be pretty low priority.

Could you try and fix it one way or another? If it's important enough for you, probably. Give it a shot: find a better way of handling those plugins and dependencies, and file a bug or feature request, or get on the appropriate forum/mailing list for this type of thing.
Open source distros don't get better by magic. If you care enough about this, get involved.

share|improve this answer

why XChat, despite having clearly been built with --enable-tcl or equivalent passed to the configure script, can be installed without a mandatory dependency on the tcl package?

You are using Arch Linux. From the FAQ - What makes Arch unique...:

Arch packaging is designed to be minimal, and optional package dependencies are never automatically installed. Rather, the user is simply notified of their existence during package installation, resulting in a slimmer system.

XChat package details:

hicolor-icon-theme libnotify
enchant (optional) - for spell checking support
python2 (optional) - for python plugin
tcl (optional) - for tcl plugin

EDIT: In reply to your comment below:

I'm not sure I get your meaning there... Optional dependencies are only used for certain features/functionalities of an application. Those dependencies are NOT needed if the said features aren't used. Optional dependencies are usually used when, for various reasons, it's not really possible to split a package into sub-modules (a sub-module would have only non-optional dependencies since you'd need all of them in order to use that sub-module's functionality). An example of package + sub-modules is exaile.

Now, about that particular error/warning message that you were getting there... I think Mat pretty much summed it up in his post and I really have nothing more to add.

share|improve this answer
But I wonder why missing packages that lead to "not found" entries are considered optional. – Francesco Turco Sep 24 '12 at 8:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.