Re: [elinks-dev] Solaris build fixes
On Tue, Jun 05, 2007 at 12:29:46AM +0300, Kalle Olavi Niemitalo wrote:
John Hawkinson [EMAIL PROTECTED] writes:
Kalle Olavi Niemitalo [EMAIL PROTECTED] wrote on Sun, 3 Jun 2007
at 10:48:09 +0300 in [EMAIL PROTECTED]:
Have you tested the resulting binary, especially with slow sites
and Transfer-Encoding: chunked?
I have not...do you have a good test case?
-
#! /usr/bin/perl
use strict;
use IPC::Open2;
print EOH;
Content-Type: text/plain
Content-Encoding: gzip
EOH
local $| = 1;
open PLAIN, , /home/Kalle/src/elinks-0.12/COPYING or die;
my $pid = open2(\*GZIP, PLAIN, gzip -1);
local $/ = \4567;
while (GZIP) { print; sleep 1 }
-
If I comment out the gzclearerr call in gzip_read, the output is
truncated after that is to say, a work. With different input
files, ELinks can display garbage too. No such problems in
ELinks 0.11.3.
Would it be sufficient to call clearerr() on the fd that
gzip_open() was called with? I guess it would be hairy to save
the fd.
clearerr() needs a FILE *, not a file descriptor. And
gzip_open() calls fdopen() itself, so ELinks never sees
the FILE *. There is no function in zlib for retrieving
the pointer, either.
So then, there seem to be four options:
(a) Just skip gzclearerr and ignore the resulting corruption.
This would be a regression from 0.11.3.
(b) Revert all the decompression changes from elinks-0.12,
returning to what was in ELinks 0.11.3.
The old code doesn't work well everywhere, so gzclearerr was added
and then the decompression code was simplified (?).
(c) Partially or completely disable gzip decompression on
platforms that don't have gzclearerr. Document that ELinks
needs at least zlib 1.2.0.2 for full support.
(d) Rewrite the decompression code or at least the gzip part of
it. I don't have an estimate on how long this would take.
It would be too easy to slip in new bugs in this process.
(e) Write ELinks's gzclearerr using internals of the zlib of Solaris 10.
Check for gzclearerr in ./configure. If it fails use own function
and warn the user.
I think it would be best to do (c) in 0.12.GIT and (d) in 0.13.GIT.
I wonder what happens when part of the gzip header is in the first chunk
and the rest in the next one.
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Solaris build fixes
Witold Filipczyk [EMAIL PROTECTED] writes: On Tue, Jun 05, 2007 at 12:29:46AM +0300, Kalle Olavi Niemitalo wrote: clearerr() needs a FILE *, not a file descriptor. And gzip_open() calls fdopen() itself, so ELinks never sees the FILE *. I should have written that gz_open() in zlib calls fdopen() itself. gzip_open() in ELinks calls gzdopen(), which calls gz_open(). (b) Revert all the decompression changes from elinks-0.12, returning to what was in ELinks 0.11.3. The old code doesn't work well everywhere, so gzclearerr was added and then the decompression code was simplified (?). Where does it not work? Is there a test case? (e) Write ELinks's gzclearerr using internals of the zlib of Solaris 10. Check for gzclearerr in ./configure. If it fails use own function and warn the user. I fear that would cause crashes later when Sun upgrades zlib and changes struct gz_stream. Probably the upgrade would be to a version later than zlib 1.2.0.2 though, so recompiling ELinks would then fix the crashes. (I did implement a similar hack in do_fsp(), but that reads only an integer and not a pointer, so it won't crash even if the result is wrong.) Then there may also be other operating systems with different old versions of zlib. Does zlib 1.1.4 as shipped in Solaris 10 include any Sun patches that change the definition of struct gz_stream in gzio.c? How hard is it for Solaris 10 users to install a newer version of zlib, e.g. in /usr/local? (f) Include recent zlib sources with ELinks and link it statically if the installed version is not suitable. http://www.fsf.org/licensing/licenses/index_html says the zlib license is compatible with GNU GPL (as it should if ELinks is already linking with it). But the required changes in the build system might already be more complex than (d) rewriting the decompression code in ELinks. I wonder what happens when part of the gzip header is in the first chunk and the rest in the next one. I did not see any bugs in 0.12.GIT when I ran the test CGI with a block size of one byte (and a shorter sleep). pgpcsdLFUv6Bj.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Solaris build fixes
John Hawkinson [EMAIL PROTECTED] writes:
--- src/encoding/gzip.c 2007/05/31 22:40:05 1.1
+++ src/encoding/gzip.c 2007/06/02 22:22:20
@@ -33,7 +33,9 @@
static int
gzip_read(struct stream_encoded *stream, unsigned char *data, int len)
{
+#ifdef HAVE_GZCLEARERR
gzclearerr((gzFile *) stream-data);
+#endif
return gzread((gzFile *) stream-data, data, len);
}
I see. The gzclearerr function was added in zlib 1.2.0.2,
released on 2003-07-13. elinks-0.12/doc/installation.txt and
elinks-0.12/INSTALL do not currently list any version requirement
for zlib.
Have you tested the resulting binary, especially with slow sites
and Transfer-Encoding: chunked? The call was added to ELinks in
commit d2b8e06f418f99c64a1a0f7ad4b3b906ced8617f:
gzip_read: always call gzclearerr
This is necessary when using a POSIX-compliant stdio implementation, which
will set the FILE error flag when input from the pipe is exhausted, causing
all subsequent reads to fail.
Can we assume that on Solaris 10 which does not have gzclearerr,
stdio does not actually set the flag? Otherwise, can we work
around the problem by disabling Accept-Encoding: gzip when
gzclearerr is not available?
I think the encoding layer in ELinks should be rewritten to avoid
stdio entirely, but I was hoping ELinks 0.12.0 could be released
first. If 0.12.GIT with this patch truncates documents but
0.11.3 does too, then the bug is not a regression and ELinks
could be released with it. So please also test 0.11.3 (or the
upcoming 0.11.4) if possible.
pgp2A8u2tlaSi.pgp
Description: PGP signature
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] Solaris build fixes
John Hawkinson [EMAIL PROTECTED] wrote Sat, Jun 02, 2007:
Hi, I'm not the list. Here are some fixes to build under Solaris 10
(no -rdynamic, no gzclearerr()). Against elinks-0.12-20070601.
Also included is a patch to add more help for -dump-color-mode.
[EMAIL PROTECTED]
John Hawkinson
--- configure.in 2007/06/01 19:18:56 1.1
+++ configure.in 2007/06/02 22:21:07
@@ -256,10 +256,21 @@
dnl
dnl FIXME: This check doesn't work. Something to do with the compiler
dnl happily ignoring it and stderr not being checked for error messages.
+dnl This works instead:
AC_MSG_CHECKING([for -rdynamic])
LDFLAGS_X=$LDFLAGS
LDFLAGS=$LDFLAGS -rdynamic
-AC_TRY_LINK([], [], have_rdynamic=yes, have_rdynamic=no)
+cat conftest.$ac_ext _ACEOF
+int main() { return 0; }
+_ACEOF
+(eval $ac_compile) 2conftest.er1
+(eval $ac_link) 2conftest.err
+if test -s conftest.err
+then
+ have_rdynamic=no
+else
+ have_rdynamic=yes
+fi
test $have_rdynamic = no LDFLAGS=$LDFLAGS_X
AC_MSG_RESULT($have_rdynamic)
Wow, this is really great. A lot of people has mentioned this over the
years and so finally being able to provide a fix is very helpful.
--
Jonas Fonseca
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
[elinks-dev] Solaris build fixes
Hi, I'm not the list. Here are some fixes to build under Solaris 10
(no -rdynamic, no gzclearerr()). Against elinks-0.12-20070601.
Also included is a patch to add more help for -dump-color-mode.
[EMAIL PROTECTED]
John Hawkinson
--- configure.in2007/06/01 19:18:56 1.1
+++ configure.in2007/06/02 22:21:07
@@ -256,10 +256,21 @@
dnl
dnl FIXME: This check doesn't work. Something to do with the compiler
dnl happily ignoring it and stderr not being checked for error messages.
+dnl This works instead:
AC_MSG_CHECKING([for -rdynamic])
LDFLAGS_X=$LDFLAGS
LDFLAGS=$LDFLAGS -rdynamic
-AC_TRY_LINK([], [], have_rdynamic=yes, have_rdynamic=no)
+cat conftest.$ac_ext _ACEOF
+int main() { return 0; }
+_ACEOF
+(eval $ac_compile) 2conftest.er1
+(eval $ac_link) 2conftest.err
+if test -s conftest.err
+then
+ have_rdynamic=no
+else
+ have_rdynamic=yes
+fi
test $have_rdynamic = no LDFLAGS=$LDFLAGS_X
AC_MSG_RESULT($have_rdynamic)
@@ -285,6 +296,7 @@
AC_CHECK_FUNCS(getifaddrs getpwnam inet_pton inet_ntop)
AC_CHECK_FUNCS(fflush fsync fseeko ftello sigaction)
AC_CHECK_FUNCS(gettimeofday clock_gettime)
+AC_CHECK_FUNCS(gzclearerr)
AC_HAVE_FUNCS(cygwin_conv_to_full_win32_path)
--- src/encoding/gzip.c 2007/05/31 22:40:05 1.1
+++ src/encoding/gzip.c 2007/06/02 22:22:20
@@ -33,7 +33,9 @@
static int
gzip_read(struct stream_encoded *stream, unsigned char *data, int len)
{
+#ifdef HAVE_GZCLEARERR
gzclearerr((gzFile *) stream-data);
+#endif
return gzread((gzFile *) stream-data, data, len);
}
--- src/config/cmdline.c2007/06/02 21:44:28 1.1
+++ src/config/cmdline.c2007/06/02 22:12:42
@@ -766,9 +766,19 @@
dump-charset, 0, document.dump.codepage,
N_(Codepage used when formatting dump output.)),
- INIT_OPT_CMDALIAS(, N_(Color mode used with -dump),
+ INIT_OPT_CMDALIAS(,
+N_(Color mode used with -dump;
+ takes a parameter from -1 to 4),
dump-color-mode, 0, document.dump.color_mode,
- N_(Color mode used with -dump.)),
+ N_(Color mode used with -dump.\n
+ Takes a parameter:\n
+-1: is standard dump mode\n
+ 0: is mono mode\n
+ 1: is 16 color mode\n
+ 2: is 88 color mode\n
+ 3: is 256 color mode\n
+ 4: is true color mode
+ )),
INIT_OPT_CMDALIAS(, N_(Width of document formatted with -dump),
dump-width, 0, document.dump.width,
___
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
