Re: [xml] built libxml and libxslt, possible bugs

Hi all,

  I hope no-one will object if I return to one of the technical
points of this posting:

Daniel Veillard said:
On Tue, Nov 11, 2003 at 02:32:06PM +0100, Tobias Reif wrote:
Hi Daniel et al,

I just finished compiling and installing (under my home dir, not
system-wide) the latest libxml and libxslt on SuSE 9.0 [uname]. I
don't know if I have a problem or not; if none of the below is an
issue then everything should be OK.

[...] libxslt-1.1.0 $ make
[generated many warnings like this one:]
pattern.c:1237: warning: comparison is always true due to limited
range of
data type
[... which probably is no problem.]

  Not a big deal, new gcc optimizer defeated some macro handling, I
them too on Fedora Core 1.

Hmmm... maybe not a big deal for you, but for me it's a terrible
insult :-).  I spent significant time putting in new routines for
character validation which should have eliminated this particular
warning.  This report would mean one of 3 things:
1) I have made some mistake (IMHO this is not possible, but I
mention it for completeness :-);
2) the version of GCC (or other compiler) you are using has a
problem (an attractive option, since it would mean both you and I
have done nothing wrong);
3) there is some problem in the setup of the source compilation

First let me show you the relevant results on my system ("up to
date" Gentoo [stable]) system:
bill bbrack workdir $ uname -a
Linux 2.4.21 #2 Sat Jun 14 10:56:58 PDT 2003 i686 AMD
Athlon(tm) XP 2200+ AuthenticAMD GNU/Linux
 (I know, this should be 2.4.22, but there's a bug in the eth driver)

bill bbrack workdir $ gcc --version
gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There
is NO
bill bbrack workdir $ cd libxml2-2.6.2/
bill bbrack libxml2-2.6.2 $ ./configure
bill bbrack libxml2-2.6.2 $ make > make.log 2>make.err
bill bbrack libxml2-2.6.2 $ cat make.err
libxml2-py.c: In function `libxml_xmlErrMemory':
libxml2-py.c:4173: warning: implicit declaration of function
bill bbrack libxml2-2.6.2 $
  (as a sidenote, the above warning is fixed in CVS :-)

bill bbrack libxml2-2.6.2 $ cd ../libxslt-1.1.0/
bill bbrack libxslt-1.1.0 $ ./configure \
bill bbrack libxslt-1.1.0 $ make > make.log 2>make.err
bill bbrack libxslt-1.1.0 $ cat make.err
preproc.c: In function `xsltDocumentComp':
preproc.c:207: warning: unused variable `URL'
bill bbrack libxslt-1.1.0 $
  (another sidenote - the above warning is also fixed in CVS)

So, for the two warnings above (nicely balanced, one in each
library) I will take full responsibility, and can only state in my
defense that they were both fixed soon after the release.  For your
"many warnings like this one", however, I am ready to go to war!

Now, (a little) more seriously:  The line you point out (pattern.c
line 1237) contains the macro SKIP_BLANKS.  That macro is defined
within the source file, but it in turn uses the macro IS_BLANK. 
IS_BLANK is defined within libxml2 (libxml/parserInternals.h), and
was enhanced (by me) prior to release 2.6.x to assure this warning
wouldn't occur.  For you, the warning DID occur, and that implies
when you compiled the libxslt library you were not getting the
correct include file (and it may also imply you weren't getting the
"right" libxml2 libraries as well).

The most likely way for this to happen (or perhaps I should say "my
best guess") would be during the configuration phase of libxslt. 
Notice in my example above, it is necessary to use the
--with-libxml-src={directory path} if (as you are doing) you want to
use a version of libxml2 which is different than the one installed
on your system.  Also, although it is not clearly set down anywhere
(I learned it through bitter experience), the directory path must be
*absolute*, _not_ relative!

So - if my guess is not correct, give me some more information to
help narrow down the problem.  On the other hand, if I'm right, then
try re-configuring libxslt (using the --with-libxml-src flag), then
"make clean" and "make" again (or better, do as in my example and
separate the make log file from the errors/warnings with
2>make.err), then post the make.err file for further analysis.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]