Irssi core bugs

Notice: Undefined index: tasklist_type in /var/www/bugs.irssi.org/includes/class.tpl.php(128) : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /var/www/bugs.irssi.org/includes/class.tpl.php(128) : eval()'d code on line 90
  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category proxy
  • Assigned To No-one
  • Operating System Windows
  • Severity Medium
  • Priority Normal
  • Reported Version Irssi 0.8.12
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Irssi core bugs
Opened by Ryan McClure (McC) - 2009-01-10

FS#637 - Windows installer / USB package does not have proxy support

According to Joshua Dick's site, linked from the main page, the Windows installer and USB drive version of Irssi comes "with built-in Perl scripting and proxy support." The files libirc_proxy and libirc_proxy.la are included in the /lib/irssi/modules folder underneath the Irssi root folder. However, when one types /load after launching the Irssi client via irssi.bat, Proxy is not listed among the modules. Typing /load proxy will predictably yield an error message stating "Irssi: Error loading module proxy/core: No such file or directory"

This task does not depend on any other tasks.

Ryan McClure (McC)
Saturday, 10 January 2009, 22:12 GMT
Minor correction to the above: the two files in the /lib/irssi/modules folder are libirc_proxy.a and libirc_proxy.la (omitted the first file's extension in original write-up).

I tried a make clean rather than a make, with the following output:
$ make clean
rm -f libirc_proxy.a
rm -rf .libs _libs
test -z "libirc_proxy.la" || rm -f libirc_proxy.la
rm -f "./so_locations"
rm -f *.o
rm -f *.lo

The result of this is the following directory tree, under /src/irc/proxy:
.deps/dump.Plo
.deps/listen.Plo
.deps/proxy.Plo
Makefile.am
dump.c
listen.c
proxy.c
module.h
Makefile
Makefile.in

Then running make, this is the output:
if /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -I../../../src/core/ -I../../../sr
c/irc/core/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DUSEIMPORTLIB -Wall -MT proxy.lo -MD -MP -MF ".deps/proxy.Tpo" -c -o
proxy.lo proxy.c; \
then mv -f ".deps/proxy.Tpo" ".deps/proxy.Plo"; else rm -f ".deps/proxy.Tpo"; exit 1; fi
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -I../../../src/core/ -I../../../src/irc/core/ -I/usr/include/glib-2.0 -I/usr/lib/glib
-2.0/include -DUSEIMPORTLIB -Wall -MT proxy.lo -MD -MP -MF .deps/proxy.Tpo -c proxy.c -DPIC -o .libs/proxy.o
gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -I../../../src/core/ -I../../../src/irc/core/ -I/usr/include/glib-2.0 -I/usr/lib/glib
-2.0/include -DUSEIMPORTLIB -Wall -MT proxy.lo -MD -MP -MF .deps/proxy.Tpo -c proxy.c -o proxy.o >/dev/null 2>&1
if /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -I../../../src/core/ -I../../../sr
c/irc/core/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DUSEIMPORTLIB -Wall -MT dump.lo -MD -MP -MF ".deps/dump.Tpo" -c -o d
ump.lo dump.c; \
then mv -f ".deps/dump.Tpo" ".deps/dump.Plo"; else rm -f ".deps/dump.Tpo"; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -I../../../src/core/ -I../../../src/irc/core/ -I/usr/include/glib-2.0 -I/usr/lib/glib
-2.0/include -DUSEIMPORTLIB -Wall -MT dump.lo -MD -MP -MF .deps/dump.Tpo -c dump.c -DPIC -o .libs/dump.o
gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -I../../../src/core/ -I../../../src/irc/core/ -I/usr/include/glib-2.0 -I/usr/lib/glib
-2.0/include -DUSEIMPORTLIB -Wall -MT dump.lo -MD -MP -MF .deps/dump.Tpo -c dump.c -o dump.o >/dev/null 2>&1
if /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -I../../../src/core/ -I../../../sr
c/irc/core/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DUSEIMPORTLIB -Wall -MT listen.lo -MD -MP -MF ".deps/listen.Tpo" -c
-o listen.lo listen.c; \
then mv -f ".deps/listen.Tpo" ".deps/listen.Plo"; else rm -f ".deps/listen.Tpo"; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -I../../../src/core/ -I../../../src/irc/core/ -I/usr/include/glib-2.0 -I/usr/lib/glib
-2.0/include -DUSEIMPORTLIB -Wall -MT listen.lo -MD -MP -MF .deps/listen.Tpo -c listen.c -DPIC -o .libs/listen.o
gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -I../../../src/core/ -I../../../src/irc/core/ -I/usr/include/glib-2.0 -I/usr/lib/glib
-2.0/include -DUSEIMPORTLIB -Wall -MT listen.lo -MD -MP -MF .deps/listen.Tpo -c listen.c -o listen.o >/dev/null 2>&1
rm -f libirc_proxy.a
ln -s .libs/libirc_proxy.a libirc_proxy.a
/bin/sh ../../../libtool --tag=CC --mode=link gcc -DUSEIMPORTLIB -Wall -o libirc_proxy.la -rpath /cygdrive/c/irssi/lib/irssi/modules -m
odule proxy.lo dump.lo listen.lo
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries
ar cru .libs/libirc_proxy.a proxy.o dump.o listen.o
ranlib .libs/libirc_proxy.a
creating libirc_proxy.la
(cd .libs && rm -f libirc_proxy.la && ln -s ../libirc_proxy.la libirc_proxy.la)

Resulting in the following directory tree:
.deps/dump.Plo
.deps/listen.Plo
.deps/proxy.Plo
.libs/libirc_proxy.a
.libs/libirc_proxy.lai
.libs/dump.o
.libs/listen.o
.libs/proxy.o
.libs/libirc_proxy.la (shows as a shortcut)
Makefile.am
dump.c
listen.c
proxy.c
module.h
Makefile
Makefile.in
libirc_proxy.la
dump.lo
listen.lo
proxy.lo
dump.o
listen.o
proxy.o
libirc_proxy.a (shows as shortcut)

The only suspcious line from the Make command is this one:
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries

I'm not familiar enough with the Make process to know the significance of that message.
Josh Dick (tidalwav1)
Sunday, 11 January 2009, 21:10 GMT
A handful of individuals have actually privately contacted me about this issue, and every time I've tried to investigate it, I've gotten nowhere.

My compilation instructions that are available at http://svn.irssi.org/repos/contrib/w32installer/shared/README.txt say to configure irssi 0.8.12 for compilation this way:

CFLAGS='-DUSEIMPORTLIB' ./configure --with-proxy --with-perl-staticlib --prefix=/cygdrive/c/irssi

I thought that --prefix=/cygdrive/c/irssi might be causing this issue, since in the finished version of the Irssi Windows binary, irssi is obviously not installed to this directory. However, I appear to be wrong on two counts:

1) Attempting to configure irssi exactly as specified above, and then compiling, will build with no issues but will not run when typing /cygdrive/c/irssi/bin/irssi.exe into a Cygwin terminal. The binary crashes and destroys the Cygwin terminal, displaying the EXACT SAME behavior described in bug 299 (http://bugs.irssi.org/index.php?do=details&task_id=299). I've never had this problem in the past, so I'm attributing it to changes in Cygwin's Perl implementation since the last time I tried compiling irssi this way. The person who filed bug 299 left a comment in the bug that says that specifying a --prefix that wasn't part of Cygwin solved the issue for him, but the issue is still there for me even when using --prefix=/cygdrive/c/irssi as described above. My Cygwin installation contains only the packages specified in the README linked above.

2) Configuring irssi WITHOUT Perl support, using CFLAGS='-DUSEIMPORTLIB' ./configure --with-proxy --with-perl=no --prefix=/cygdrive/c/irssi as described in the README linked above, yields a working binary. However, without doing any folder restructuring as described in my README (in other words, running the binary from the --prefix location it was originally placed in by 'make install'), the proxy module is STILL not available. This leads me to believe that it's NOT an issue with --prefix or with repackaging/redistribution as I originally thought, but now I have no idea what the actual problem is.

There are two other issues that some users have reported to me that COULD be related to this one:

***NOTE:*** Whenever I say 'compiled from scratch' below, I mean compiling irssi inside Cygwin and then running it from the location specified by --prefix.

The first one is the fact that in the irssi-win32 binaries that are currently being distributed, irssi's '/help [command]' command does not work. Typing '/help' lists all available irssi commands, but typing '/help [command]' yields 'No help for [command].' This is odd since all of the help pages are present in .\share\irssi\help in either distribution. Of course, typing '/help [command]' works fine after compiling irssi from scratch.

The second one is the fact that irssi's '/away' command is partially broken, both in the irssi-win32 binaries that are currently being distributed as well as after compiling irssi from scratch. When one returns from away, their messages are not displayed even though the message count is correctly displayed. Here is example output:

16:00 -!- You have been marked as being away
16:00 -!- You are no longer marked as being away
16:00 -!- Irssi: 1 new messages in awaylog:
[end of output]

As you can see, the messages aren't actually displayed.

I feel like most or even all of the issues described here could have something to do with the --prefix that is specified during configuration, combined with the fact that end users obviously don't run irssi from the directory specified in --prefix when using the irssi-win32 binaries/packages that I helped create. There are probably other irssi features that depend on --prefix that are also broken in the current irssi-win32 binaries that haven't been seen/found/reported yet. As already mentioned, /help works when compiling from scratch, but the other issues described here are all present either when compiling from scratch OR inside the currently distributed irssi-win32 binaries/packages.

So, to recap, here's a list of issues just described (if needed, I'll file separate bugs for the previously undiscussed ones:)

1) Compiling irssi under Cygwin with Perl support seems to produce a broken binary.
2) No proxy module is available after configuring irssi with --with-proxy (both in the irssi-win32 packages and when compiling from scratch.)
3) No '/help' entries are visible in the currently distributed irssi-win32 packages (but work fine when compiling from scratch.)
4) '/away' command is broken in the currently distributed irssi-win32 packages; it doesn't show queued messages when returning from away (both in the irssi-win32 packages and when compiling from scratch.)
5) Most if not all of these issues probably stem from the use of --prefix, but I could be wrong, and would love to be steered in the right direction so all of these issues can be ironed out.

Sorry for the large amount of writing, I tried to make this as detailed and thorough as possible.

Any thoughts? (Wouter, I'm looking at you!) ;)
Ryan McClure (McC)
Sunday, 11 January 2009, 21:18 GMT
Thanks for the thorough response, Josh!

I also noticed the broken binary issue when attempting to compile irssi "from scratch" with Perl support. I did not attempt to compile it without perl support, but it seems that even if I had done so, it would not have created the proxy module that I seek.
Jon Wickström (trace)
Monday, 02 February 2009, 12:56 GMT
I traced filesystem activity. By default a /load proxy tries to load modules (by a lot of guessing) from the users profile (Application data) and from "c:\irssi\lib\irssi\modules" it never looks at my install under c:\program files\irssi. I installed with the windows installer. Irssi is started with the argument --home pointing to [profile}\application data\irssi.

It first tries various versions of the module name with extensions .exe, .dll, .lnk, .exe.lnk, .dll.lnk, .dll.la.exe, .dll.la.lnk, .dll.la.exe.lnk (I might have missed one or two...). It also tries with varous suffixes for the module, including cygproxy, cygproxy_core, cygfe_proxy, cygfe_common_proxy, cygirc_proxy, cygfe_irc_proxy, cygfe_common_irc_proxy, cygsilc_proxy, cygfe_silc_proxy, cygfe_common_silc_proxy, cygproxy_core (I might have missed one here too...). All the modules are tried with all the extensions.

Doing "/load libirc_proxy" gives a little different module name ("proxy/irc", not "proxy/core"). Creating the c:\irssi\lib\irssi\modules and copying in the content from c:\program files\irssi\lib\irssi\modules does not help.

My wild guess is that something in the build process is not building the .dll or .exe or that opening of the libtool library file is broken?

In my c:\program files\irssi\lib\irssi\modules directory I have libirc_proxy.a and libirc_proxy.la. The later being a libtool library file with the following content:
--8<---
# libirc_proxy.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libirc_proxy.a'

# Libraries that this one depends upon.
dependency_libs=''

# Version information for libirc_proxy.
current=0
age=0
revision=0

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=yes

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/cygdrive/c/irssi/lib/irssi/modules'
--8<---

If I copy libirc_proxy.la to libirc_proxy.dll.la, then irssi opens and reads it. It then tries to open c:\irssi\lib\irssi\modules\.dll
Jon Wickström (trace)
Friday, 20 February 2009, 04:31 GMT
Josh Dick noted that the "/help <command>" is not working. I have help_path pointing to /cygdrive/c/irssi/share/irssi/help, which is not where irssi is installed. Changeing it to /cygdrive/c/Program Files/irssi/share/irssi/help makes the help work.
Austin Brkich (KuraKai)
Sunday, 22 February 2009, 06:05 GMT
I am also having this same issue, I am kind of surprised this has been going on for some time to be honest...
Antoine Turmel (GeekShadow)
Wednesday, 02 November 2011, 16:51 GMT
I installed the 0.8.15 (Windows Installer) and doesn't have the proxy too.

Loading...