From mingo at elte.hu Sun Aug 1 18:06:39 2004 From: mingo at elte.hu (Ingo Molnar) Date: Sun, 1 Aug 2004 20:06:39 +0200 Subject: Tux for 2.6.7 (or 2.6.8) In-Reply-To: <1091027000.23836.42.camel@mcdlp.pbi.daviesinc.com> References: <1091027000.23836.42.camel@mcdlp.pbi.daviesinc.com> Message-ID: <20040801180639.GA10572@elte.hu> * Chris Davies wrote: > I notice on > > http://people.redhat.com/mingo/TUX-patches/ > > the latest 2.6 kernel supported is 2.6.5 > > I tried applying the patches to 2.6.7, but they don't apply cleanly. > When 2.6.8 is released, will there be an updated patch file made > available? the most recent port of Tux is in Arjan's kernel rpms (which are also the rpms used for Fedora 2 and 3): http://redhat.com/~arjanv/2.6/ the Tux patch in the SRPM should apply to vanilla kernels too. Ingo From mingo at elte.hu Thu Aug 12 10:10:58 2004 From: mingo at elte.hu (Ingo Molnar) Date: Thu, 12 Aug 2004 12:10:58 +0200 Subject: tux - incomplete requests In-Reply-To: <20040812101915.GC15386@chewbacca.enseirb.fr> References: <20040812101915.GC15386@chewbacca.enseirb.fr> Message-ID: <20040812101058.GA26246@elte.hu> it will be pushed into the workqueue next time the networking layer sees any event happening on that socket. (or a timeout occurs.) Ingo * sapan at chewbacca.enseirb.fr wrote: > hi, > > in which function do incomplete tux requests get pushed back into the > workqueue? > > i notice that if proto->parse_request returns 0 (signalling an incomplete > request), parse_request simply calls add_tux_atom(req, parse_request) without > calling add_req_to_workqueue, which makes sense since otherwise > process_requests might loop forever, resulting in a busy-poll... > but in that case, where does the incomplete request get pushed back > into the workqueue? > > sapan From johannburkard at arcor.de Fri Aug 13 21:52:14 2004 From: johannburkard at arcor.de (johannburkard at arcor.de) Date: Fri, 13 Aug 2004 23:52:14 +0200 (CEST) Subject: Tux not reading MIME types Message-ID: <14933708.1092433934936.JavaMail.ngmail@webmail06.arcor-online.net> Hi, I have set up a new server. Tux' MIME types are in /etc/tux.mime.types, as usual, but Tux does not read it - html files are served as text/plain. What could be wrong? Greetings, Johann Arcor-DSL: jetzt ohne Einrichtungspreis einsteigen oder wechseln Sie sparen 99,95 Euro. Arcor-DSL ist in vielen Anschlussgebieten verf?gbar. http://www.arcor.de/home/redir.php/emf-dsl-1 From jb at eaio.de Sun Aug 15 18:31:11 2004 From: jb at eaio.de (Johann Burkard) Date: Sun, 15 Aug 2004 20:31:11 +0200 Subject: Tux not reading MIME types References: <14933708.1092433934936.JavaMail.ngmail@webmail06.arcor-online.net> Message-ID: <000701c482f6$0c2fee50$2100a8c0@granularr> Hi, johannburkard at arcor.de wrote: > I have set up a new server. Tux' MIME types are in > /etc/tux.mime.types, as usual, but Tux does not read it - html files > are served as text/plain. could someone help me with this? Tux still serves everything as text/plain... Thanks, Johann From m.rothley at dress-for-less.de Sun Aug 15 19:15:17 2004 From: m.rothley at dress-for-less.de (Marco Rothley) Date: Sun, 15 Aug 2004 21:15:17 +0200 Subject: Tux not reading MIME types In-Reply-To: <000701c482f6$0c2fee50$2100a8c0@granularr> References: <14933708.1092433934936.JavaMail.ngmail@webmail06.arcor-online.net> <000701c482f6$0c2fee50$2100a8c0@granularr> Message-ID: <200408152115.17223.m.rothley@dress-for-less.de> Am Sonntag, 15. August 2004 20:31 schrieb Johann Burkard: > Hi, > > johannburkard at arcor.de wrote: > > I have set up a new server. Tux' MIME types are in > > /etc/tux.mime.types, as usual, but Tux does not read it - html files > > are served as text/plain. > > could someone help me with this? Tux still serves everything as > text/plain... Hello Johann! A little more information would be helpful. Are you sure, the page is served by TUX? How does your tux.mime.types file look like? Are other files served correctly? ... Marco. From jb at eaio.de Sun Aug 15 19:36:18 2004 From: jb at eaio.de (Johann Burkard) Date: Sun, 15 Aug 2004 21:36:18 +0200 Subject: Tux not reading MIME types References: <14933708.1092433934936.JavaMail.ngmail@webmail06.arcor-online.net><000701c482f6$0c2fee50$2100a8c0@granularr> <200408152115.17223.m.rothley@dress-for-less.de> Message-ID: <000d01c482ff$282018c0$2100a8c0@granularr> Hi, Marco Rothley wrote: > A little more information would be helpful. Are you sure, the page is > served by TUX? How does your tux.mime.types file look like? Are other > files served correctly? ... there was a problem with Gentoo's tux-3.2.16.ebuild that wouldn't want to compile on my machine, so I took tux and tux2w3c from another machine with a 2.4.18 kernel. Now I have 2.6.5 and tux basically works, but the MIME types are not working: (GET / HTTP/1.0) HTTP/1.1 200 OK Content-Type: text/plain Date: ed, 01 Jan 1970 00:00:01 GMT Server: TUX/2.0 (Linux) Content-Length: 5113 ETag: "5113-ebangejn" Accept-Ranges: bytes Last-Modified: Sun, 01 Aug 2004 21:46:05 GMT Even images are served as text/plain. Here's the /etc/tux.mime.types file: # This is the default mime.types file from the TUX web server distribution # # there are two MIME-types intercepted by TUX: # # - all extensions listed after TUX/redirect will be redirected # to the secondary server. # - all extensions listed after TUX/CGI will be handled by the # TUX CGI engine directly. # - all extensions listed after TUX/module will be handled by # TUX userspace modules. # # MIME type Extension TUX/redirect redir WEB-INF jsp TUX/CGI cgi pl TUX/module tux x application/msword doc application/octet-stream bin dms lha lzh exe class application/pdf pdf application/rtf rtf application/smil smi smil application/x-bzip2 bz2 application/x-gtar gtar application/x-gzip gz tgz application/x-javascript js application/x-shockwave-flash swf application/x-tar tar audio/mpeg mpga mp2 mp3 audio/x-pn-realaudio ram rm audio/x-realaudio ra audio/x-wav wav image/gif gif image/jpeg jpeg jpg jpe image/png png image/tiff tiff tif model/vrml wrl vrml text/css css text/plain asc txt text/richtext rtx text/rtf rtf text/sgml sgml sgm text/tab-separated-values tsv text/xml xml xsl xslt video/mpeg mpeg mpg mpe video/quicktime qt mov video/x-msvideo avi text/html html htm xhtml xhtm Greetings, Johann From mcd at daviesinc.com Sun Aug 15 21:56:49 2004 From: mcd at daviesinc.com (Chris Davies) Date: Sun, 15 Aug 2004 17:56:49 -0400 Subject: Tux not reading MIME types In-Reply-To: <000d01c482ff$282018c0$2100a8c0@granularr> References: <14933708.1092433934936.JavaMail.ngmail@webmail06.arcor-online.net> <000701c482f6$0c2fee50$2100a8c0@granularr> <200408152115.17223.m.rothley@dress-for-less.de> <000d01c482ff$282018c0$2100a8c0@granularr> Message-ID: <1092607009.27026.161.camel@mcdlp.pbi.daviesinc.com> can you check on the old system and see if there are other locations for tux.mime.types? does tux have permission to read tux.mime.types? On Sun, 2004-08-15 at 21:36 +0200, Johann Burkard wrote: > HTTP/1.1 200 OK > Content-Type: text/plain > Date: ed, 01 Jan 1970 00:00:01 GMT > Server: TUX/2.0 (Linux) > Content-Length: 5113 > ETag: "5113-ebangejn" > Accept-Ranges: bytes > Last-Modified: Sun, 01 Aug 2004 21:46:05 GMT From jb at eaio.de Sun Aug 15 23:01:39 2004 From: jb at eaio.de (Johann Burkard) Date: Mon, 16 Aug 2004 01:01:39 +0200 Subject: Tux not reading MIME types References: <14933708.1092433934936.JavaMail.ngmail@webmail06.arcor-online.net><000701c482f6$0c2fee50$2100a8c0@granularr><200408152115.17223.m.rothley@dress-for-less.de><000d01c482ff$282018c0$2100a8c0@granularr> <1092607009.27026.161.camel@mcdlp.pbi.daviesinc.com> Message-ID: <000f01c4831b$d881d700$2100a8c0@granularr> Hi, Chris Davies wrote: > can you check on the old system and see if there are other locations > for tux.mime.types? does tux have permission to read tux.mime.types? tux.mime.types is 644: -rw-r--r-- 1 root root 1253 Aug 14 01:14 tux.mime.types Greetings, Johann From Viktors at Rotanovs.com Mon Aug 16 05:12:50 2004 From: Viktors at Rotanovs.com (Viktors Rotanovs) Date: Mon, 16 Aug 2004 08:12:50 +0300 Subject: Tux not reading MIME types In-Reply-To: <000d01c482ff$282018c0$2100a8c0@granularr> References: <14933708.1092433934936.JavaMail.ngmail@webmail06.arcor-online.net><000701c482f6$0c2fee50$2100a8c0@granularr> <200408152115.17223.m.rothley@dress-for-less.de> <000d01c482ff$282018c0$2100a8c0@granularr> Message-ID: <41204252.9030402@Rotanovs.com> Hi Johann, Johann Burkard wrote: > there was a problem with Gentoo's tux-3.2.16.ebuild that wouldn't want to > compile on my machine, so I took tux and tux2w3c from another machine with a > 2.4.18 kernel. Now I have 2.6.5 and tux basically works, but the MIME types > are not working: 1) check if your TUX startup script matches tux-* version and that it really starts the way you want 2) probably this is caused by version mismatch between kernel tux patch and tux-* package (maybe 2.x package and 3.0 in kernel etc.) - beware - it's impossible to tell version of kernel tux from looking at HTTP headers, but if you're using kernel 2.6, then it's tux 3.0, and on that 2.4 machine chances are that it's tux 2.2. Also check that "tux" binary can load all required libraries - change to directory containing "tux" then run "ldd tux". Hope this helps! Best Wishes, Viktors From grendel at caudium.net Wed Aug 18 15:16:57 2004 From: grendel at caudium.net (Marek Habersack) Date: Wed, 18 Aug 2004 17:16:57 +0200 Subject: tux-induced kernel BUG() with userspace modules Message-ID: <20040818151657.GB5598@beowulf.thanes.org> Hello, Working on a userspace module, I came across a problem with TUX_ACTION_REDIRECT_REQ. Unless I am doing something wrong, the following module is the simplest possible test case to reproduce the bug: #include #ifdef TUXAPI_declare TUXAPI_declare; #endif int TUXAPI_handle_events(user_req_t *req) { return tux(TUX_ACTION_REDIRECT_REQ, req); } The environment is: 1. tux: tux3 A3 rediffed for 2.4.26 and another for 2.4.26+openwall2, compiled with debugging stuff, no cgi, extended logging 2. kernel: as above, 2.4.26 vanilla, 2.4.26-ow2 3. machine: P4/1GB RAM, Athlon/1GB RAM, vmware with 256MB ram - I don't think it matters 4. tux sysctls used: net/tux/virtual_server = 0 net/tux/clientport = 81 net/tux/referer_logging = 1 net/tux/referer_blocking = 1 net/tux/logging = 1 net/tux/max_keepalives = 1000 net/tux/keepalive_timeout = 30 net/tux/TDprintk = 0 net/tux/Dprintk = 1 net/tux/generate_cache_control = 1 net/tux/generate_etags = 1 net/tux/generate_last_mod = 0 net/tux/defer_accept = 0 net/tux/all_userspace = 1 net/tux/http_subdocroot = docroot The oops itself is: Aug 18 18:50:59 localhost kernel: kernel BUG at inode.c:1204! Aug 18 18:50:59 localhost kernel: invalid operand: 0000 Aug 18 18:50:59 localhost kernel: CPU: 0 Aug 18 18:50:59 localhost kernel: EIP: 0010:[iput+578/592] Not tainted Aug 18 18:50:59 localhost kernel: EFLAGS: 00010246 Aug 18 18:50:59 localhost kernel: eax: c02cf3ec ebx: c5de7480 ecx: 00000000 edx: c5de7490 Aug 18 18:50:59 localhost kernel: esi: c7e87000 edi: 00000000 ebp: c65e2ec0 esp: c5df3e3c Aug 18 18:50:59 localhost kernel: ds: 0018 es: 0018 ss: 0018 Aug 18 18:50:59 localhost kernel: Process tux (pid: 517, stackpage=c5df3000) Aug 18 18:50:59 localhost kernel: Stack: c5de7480 c5de75a0 c11641c0 c65e2ec0 c5de7480 c5de7480 c01474a0 c5de7480 Aug 18 18:50:59 localhost kernel: c63ae6c0 c63ae6c0 c11641c0 c01356b6 c65e2ec0 c63ae6c0 c63ae6c0 c6a4ee40 Aug 18 18:50:59 localhost kernel: 00000000 00000000 c0133dcd c63ae6c0 c6a4ee40 c63ae6c0 00000000 00000000 Aug 18 18:50:59 localhost kernel: Call Trace: [dput+160/368] [fput+198/288] [filp_close+77/128] [sys_close+78/96] [] Aug 18 18:50:59 localhost kernel: [] [] [] [] [] [wake_up_process+22/32] Aug 18 18:50:59 localhost kernel: [] [] [] [] [] [] Aug 18 18:50:59 localhost kernel: [] [] [] [] [in_group_p+35/48] [path_release+21/64] Aug 18 18:50:59 localhost kernel: [sys_chdir+160/208] [sys_tux+126/128] [system_call+51/56] Aug 18 18:50:59 localhost kernel: Aug 18 18:50:59 localhost kernel: Code: 0f 0b b4 04 66 da 27 c0 e9 e1 fd ff ff 90 8b 54 24 04 8b 42 Aug 18 18:50:59 localhost kernel: Possibly unexpected TUX-thread exit(11) at c0107803? Aug 18 18:50:59 localhost kernel: TUX: thread 0 stopping ... Aug 18 18:50:59 localhost kernel: PRINT req c6960800 , sock 00000000 Aug 18 18:50:59 localhost kernel: ... idx: 0 Aug 18 18:50:59 localhost kernel: ... meth:{}, uri:{}, query:{}, ver:{} Aug 18 18:50:59 localhost kernel: ... post_data:{}(0). Aug 18 18:50:59 localhost kernel: ... headers: {} Aug 18 18:50:59 localhost kernel: PRINT req c6960800 , sock 00000000 Aug 18 18:50:59 localhost kernel: ... idx: 0 Aug 18 18:50:59 localhost kernel: ... meth:{}, uri:{}, query:{}, ver:{} Aug 18 18:50:59 localhost kernel: ... post_data:{}(0). Aug 18 18:50:59 localhost kernel: ... headers: {} The PRINT req message repeats infinitely, the machine needs to be rebooted in order to be able to do anything with tux. The interesting thing is that the redirect does take place, the backend server does deliver content and only after that the above happens. I ran tux userland under gdb since I suspected a segfault in the module somewhere (in the original on), but no segfault happened and the test module confirmed that it must have been something else. The line in inode.c says: if (inode->i_state == I_CLEAR) BUG(); but I'm not sure what inode does tux trying to put - at first I thought that it might have been a problem with the socket being killed prematurely but the above oops trace suggests it has something to do with the filesystem on disk (or /proc, perhaps?), I think. Any help will be appreciated, if more info/testing is needed - please let me know TIA, marek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jb at eaio.de Thu Aug 19 20:54:09 2004 From: jb at eaio.de (Johann Burkard) Date: Thu, 19 Aug 2004 22:54:09 +0200 Subject: Tux not reading MIME types References: <14933708.1092433934936.JavaMail.ngmail@webmail06.arcor-online.net><000701c482f6$0c2fee50$2100a8c0@granularr> <200408152115.17223.m.rothley@dress-for-less.de><000d01c482ff$282018c0$2100a8c0@granularr> <41204252.9030402@Rotanovs.com> Message-ID: <000b01c4862e$af73b570$2100a8c0@granularr> Hi everyone, Viktors Rotanovs wrote: > 1) check if your TUX startup script matches tux-* version and that it > really starts the way you want the script is taken from the 2.x utilities, but I think it should work fine. > 2) probably this is caused by version mismatch between kernel tux > patch and tux-* package (maybe 2.x package and 3.0 in kernel etc.) - > beware - it's impossible to tell version of kernel tux from looking > at HTTP headers, but if you're using kernel 2.6, then it's tux 3.0, > and on that > 2.4 machine chances are that it's tux 2.2. Also check that "tux" > binary can load all required libraries - change to directory > containing "tux" then run "ldd tux". As I said, I was trying to get the latest tux/tux2w3c binaries, but they don't compile: # emerge www-servers/tux [emerge] gcc -march=pentium3 -O3 -pipe -Wall -I. -DINTERFACE_VERSION=3 -D_LARGEFILE64 _SOURCE -o tux2w3c tux2w3c.c gcc -march=pentium3 -O3 -pipe -Wall -I. -DINTERFACE_VERSION=3 -D_LARGEFILE64 _SOURCE -o tuxstat tuxstat.c [demos] demo6.c: In function `TUXAPI_handle_events': demo6.c:37: warning: assignment makes integer from pointer without a cast demo6.c:40: warning: assignment makes integer from pointer without a cast demo6.c:59: warning: deprecated use of label at end of compound statement demo5.c: In function `TUXAPI_handle_events': demo5.c:25: warning: assignment makes integer from pointer without a cast make -C docs all make[1]: Entering directory `/var/tmp/portage/tux-3.2.16/work/tux-3.2.16/docs' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/var/tmp/portage/tux-3.2.16/work/tux-3.2.16/docs' make: pkg-config: Command not found gcc -march=pentium3 -O3 -pipe -Wall -I. -DINTERFACE_VERSION=3 -D_LARGEFILE64 _SOURCE -c tux.c [demos] tux.c:23:18: glib.h: No such file or directory tux.c: In function `handle_all_events': tux.c:51: error: can't find a register in class `BREG' while reloading `asm' tux.c:51: error: can't find a register in class `BREG' while reloading `asm' tux.c:51: error: can't find a register in class `BREG' while reloading `asm' tux.c: In function `initialize_mimetypes': tux.c:169: error: `GHashTable' undeclared (first use in this function) tux.c:169: error: (Each undeclared identifier is reported only once tux.c:169: error: for each function it appears in.) tux.c:169: error: `exts' undeclared (first use in this function) tux.c:175: warning: implicit declaration of function `g_hash_table_new' tux.c:175: error: `g_str_hash' undeclared (first use in this function) tux.c:175: error: `g_str_equal' undeclared (first use in this function) tux.c:239: warning: implicit declaration of function `g_hash_table_lookup' tux.c:240: warning: implicit declaration of function `g_hash_table_insert' tux.c:257: warning: implicit declaration of function `g_hash_table_destroy' make: *** [tux.o] Error 1 !!! ERROR: www-servers/tux-3.2.16 failed. !!! Function src_compile, Line 27, Exitcode 2 !!! (no error message) Is this error known? Could someone send me the binaries for version 3(x86, P3)? ldd tux says: # ldd tux linux-gate.so.1 => (0xffffe000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0x40018000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40020000) libdl.so.2 => /lib/libdl.so.2 (0x4004d000) libc.so.6 => /lib/libc.so.6 (0x40050000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Thanks, Johann From williama_lovaton at coomeva.com.co Fri Aug 20 19:19:40 2004 From: williama_lovaton at coomeva.com.co (William Lovaton) Date: 20 Aug 2004 14:19:40 -0500 Subject: 2.6.8 kernel for FC2 and TUX Message-ID: <1093029580.16249.53.camel@localhost.localdomain> Hi there, Is tux shipped with the new 2.6.8 for FC2? the 2.6.7 update doesnt have it. -William From nuno.ferreira at globals.pt Wed Aug 25 15:00:03 2004 From: nuno.ferreira at globals.pt (Nuno Ferreira) Date: Wed, 25 Aug 2004 16:00:03 +0100 Subject: FC2 and Tux In-Reply-To: <20040821160057.3CE0673D4C@hormel.redhat.com> Message-ID: <200408251500.i7PF01s0011389@relay.ciberguia.pt> Hi, How is Tux (not) being supported in FC2? Right now it doesn't compile with neither 2.6.7 and 2.6.8 Fecora kernels (ie, implicit references to chdir, chroot, write and read become missing symbols in the end). I hope Tux will still be supported. I personally find it the faster HTTP static web server around. Nuno From jb at eaio.de Wed Aug 25 21:01:47 2004 From: jb at eaio.de (Johann Burkard) Date: Wed, 25 Aug 2004 23:01:47 +0200 Subject: Can't compile Tux userspace utils Message-ID: <000901c48ae6$bfc22760$2100a8c0@granularr> Hi, I downloaded glib 2.0, ran ./configure && make and then tried make in tux' directory, here's the error message: $ make gcc -g -fomit-frame-pointer -O2 -Wall -I. -DINTERFACE_VERSION=3 -D_LARGEFILE 64_SOURCE -I$(top_builddir)//home/burkard/glib-2.0.0 -I$(top_builddir)//hom e/burkard/glib-2.0.0/. -I$(top_builddir)//home/burkard/glib-2.0.0/./glib - c tux.c /bin/sh: line 1: top_builddir: command not found /bin/sh: line 1: top_builddir: command not found /bin/sh: line 1: top_builddir: command not found gcc -g -fomit-frame-pointer -O2 -Wall -I. -DINTERFACE_VERSION=3 -D_LARGEFILE 64_SOURCE -lpopt $(top_builddir)//home/burkard/glib-2.0.0/glib/libglib-2.0.la -ldl -rdynami c -o tux tux.o # queue.o /bin/sh: line 1: top_builddir: command not found file://home/burkard/glib-2.0.0/glib/libglib-2.0.la: file not recognized: File format not recognized collect2: ld returned 1 exit status make: *** [tux] Error 1 Can someone tell me what's wrong here? Thanks, Johann From icedank at gmx.net Thu Aug 26 02:55:05 2004 From: icedank at gmx.net (Andrew Kirilenko) Date: Thu, 26 Aug 2004 04:55:05 +0200 (MEST) Subject: Simple tux module won't working Message-ID: <16973.1093488905@www42.gmx.net> Hello! Can somebody explain me what I'm doing wrong... Best regards, Andrew. -- Superg?nstige DSL-Tarife + WLAN-Router f?r 0,- EUR* Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl -------------- next part -------------- A non-text attachment was scrubbed... Name: tuxcache.c Type: application/octet-stream Size: 2683 bytes Desc: not available URL: From jb at eaio.de Fri Aug 27 10:18:58 2004 From: jb at eaio.de (Johann Burkard) Date: Fri, 27 Aug 2004 12:18:58 +0200 Subject: Can't compile Tux userspace utils References: <000901c48ae6$bfc22760$2100a8c0@granularr> Message-ID: <001201c48c1f$4ee56db0$2100a8c0@granularr> Johann Burkard wrote: > Can someone tell me what's wrong here? I found pkgconfig and also compiled glib, but it still doesn't compile on my box: # make gcc -g -fomit-frame-pointer -O2 -Wall -I. -DINTERFACE_VERSION=3 -D_LARGEFILE 64_SOURCE -I$(top_builddir)//root/glib-2.0.0 -I$(top_builddir)//root/glib-2 .0.0/. -I$(top_builddir)//root/glib-2.0.0/./glib -c tux.c /bin/sh: line 1: top_builddir: command not found /bin/sh: line 1: top_builddir: command not found /bin/sh: line 1: top_builddir: command not found tux.c: In function `tux': tux.c:51: error: can't find a register in class `BREG' while reloading `asm' make: *** [tux.o] Error 1 # gcc --version gcc (GCC) 3.3.4 20040623 (Gentoo Hardened Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) I was able to compile tux and tux2w3c on another machine, and finally Tux worked fine. Maybe this compilation error should be fixed. Greetings, Johann