I have set up my eggdrop fully and successfully run it with ./eggdrop -m -n eggdrop.conf and have a userfile. But when I try to run it with just ./eggdrop I have it say:
This would indicate that you've got some problems with threaded tcl-libraries.
Recently, as several linux-dists have switched to threaded tcllib-packages, there have been an issue where the "gluecode" to make your bot launch into background (with threaded tcl) either isn't implemented, or breaks for some other reason. One fix that has worked for others sofar, is to remove the deb/rpm/etc package, and install a non-threaded tcllibrary manually.
Not sure what you mean by buildtree... but I downloaded the source for the latest TCL and installed it that way. Didn't use any rpm's or the like. I'm using Fedora 5 btw.
Basically, just the files where you compiled your eggdrop (not where you installed it). Mainly interrested in the config.h and config.log files generated by ./configure.
Also, when you compiled tcl (not eggdrop), did you build it with or without thread-support? Did you install it systemwide? Made sure Fedora did'nt sneak anything related to tcl onto your system while you did'nt look?
Ok then, yes I still have the buildtree. I didn't specifically tell it to build with thread-support... so I'm going to guess no on that one. I do not believe it was a system wide install as it's located in /home/matt/eggdrop after the make install is run. How would you recommend I check on the TCL?
'k, it seems ./configure did detect a system-wide tcllib installation (at /urs/local/ ) that was not threaded (lacking TclpFinalizeThreadData). This would be coherent with a manual system-installation of tcl.
It'll probably take a couple of minutes or so, but should list any and all rpm-packages containing tcl in it's name. Just to make sure yum or such did'nt sneak tcl in there...
Yup, which means you've got two different versions of tcl on your system.
The configure-script found the one you compiled and installed, yet I'm quite confident that the compiler and the runtime loader uses the one from the rpm.
Confirmed then, your eggdrop is indeed linked to the library-files provided by the rpm, and not the ones you installed yourself. Since FC4, the rpm's hold thread-enabled tcllibraries, requiring special code to put your eggdrop in "background". Since the configure-script found, and used the other set of libraries (the ones you installed yourself), the neccesary code was not included into the eggdrop.
In this case, your two best options are:
1, uninstall the rpm-version of tcl on your system, and recompile your eggdrop.
2, remove the tcl-libraries you manually installed, and recompile your eggdrop.
I don't understand why people are having probs with threaded versions, unless perhaps its when you do have threaded tcl libs and compiled eggdrop without thread support? I compiled both the libs and eggdrop with threads enabled, works fine.
@rosc:
All issues I've encountered has been on recent Fedora, Suse, etc using dist-provided packages for tcl, where they've suddenly decided to make their tcl-libraries threaded. Sofar, pinning this one down has been very difficult, as most users have been content in compiling the library manually and shown no further interrest in providing any information to figure this one out.
Sofar, the only conclusions I've come to is that there is something strange with the builds in Fedora 4-6, Suse, etc; or the user installed multiple libraries, causing a very confused configure-script.
The information gathered in this thread covers and exceeds any and all info I've gathered from users sofar..
Anyone able to conduct a bit of an experiment, using the fedora package tcl lib with threads enabled, if you enable threads in eggdrop's configure, does that then work?
Eggdrop has no speciffic toggle or setting to enable support for threads; the configure-script tries to locate the libtcl.so file, and tests wether it comes with the function "TclpFinalizeThreadData" - which should only be present in threaded libraries.
If the tcllibrary is considdered threaded, the HAVE_TCL_THREADS macro is defined in config.h, which results in some gluecode being included in bg.c (tries to place bot in background by using fork or other tricks), and informative messages added to chanprog.c and main.c...
There is one option to prevent the detection of threaded tcl, --disable-tcl-threads, however this would only be useful when a library is falsely detected as threaded. Using this option with a threaded library will cause your bot to break as described in the beginning of this topic.