HTML::Parser 3.49 won't compile (SuSE 8.0/Perl 5.8.7)?

[Chris]

Trying to upgrade from Perl 5.6.1 -> 5.8.7 and am down to installing
various modules. I'm having an issue with hparser.c compiling in the
HTML:arser module. 99.99% of the time, a quick Google turns up the
answer to most issues, but I've been able to find nothing on this.
Gotta be one of the weirdest issues I've had on Linux and Perl
(normally, everything works like a charm, esp. in the Perl world of
things). I'm in the middle of this upgrade and I never thought this is
the place I would get stuck:

zion:/usr/local/xfer/HTML-Parser-3.49# perl Makefile.PL
Writing Makefile for HTML:arser
zion:/usr/local/xfer/HTML-Parser-3.49# make
cc -c -fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"3.49\"
-DXS_VERSION=\"3.49\" -fpic
"-I/usr/local/lib/perl5/5.8.7/i686-linux/CORE" -DMARKED_SECTION
Parser.c
In file included from Parser.xs:115:
hparser.c: In function `report_event':
hparser.c:145: parse error before `offset'
hparser.c:197: `line' undeclared (first use in this function)
hparser.c:197: (Each undeclared identifier is reported only once
hparser.c:197: for each function it appears in.)
hparser.c:298: `offset' undeclared (first use in this function)
hparser.c:300: `column' undeclared (first use in this function)
make: *** [Parser.o] Error 1

Anyone with any clues, I would appreciate it. I guess I could follow
what the compiler is saying and try and "fix it," but it strikes me
this shouldn't be happening in the first place. Gisle has tons of
packages out there and they all make, install and run very well as a
rule including this one (I know I uninstalled without a hitch under
Perl 5.6.1).

Thanks!
-ceo

 

[DJ Stunks]

zion:/usr/local/xfer/HTML-Parser-3.49# make
cc -c -fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"3.49\"
-DXS_VERSION=\"3.49\" -fpic
"-I/usr/local/lib/perl5/5.8.7/i686-linux/CORE" -DMARKED_SECTION
Parser.c

shouldn't you be compiling with gcc on linux?

-jp

 

[Chris]

shouldn't you be compiling with gcc on linux?

Yes, /usr/bin/cc is soft linked to gcc.

-ceo

 

[Sisyphus]

..
..

cc -c -fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"3.49\"
-DXS_VERSION=\"3.49\" -fpic
"-I/usr/local/lib/perl5/5.8.7/i686-linux/CORE" -DMARKED_SECTION
Parser.c

When I build that module (same version) on Mandrake linux, the exact same
command gets run and works fine. As with you, 'cc' is just a pseudonym for
'gcc'. To be precise, it's not the *exact* same command in my case - I'm
using perl-5.8.8 (which I think has *no* bearing on the problem), so
'5.8.7' is replaced with '5.8.8' - and that's the only difference I can see
..... except that your line breaks are a little "all over the place" (which I
assume is just some quirk of the way your post has been wrapped for me).


When I look at hparser.c I can't see any way that there could be a "parse
error before `offset'" on line 145:

141: if (p_state->eof)
142: return;
143:
144: /* capture offsets */
145: STRLEN offset = p_state->offset;
146: STRLEN line = p_state->line;
147: STRLEN column = p_state->column;
148:
149: #if 0
150: { /* used for debugging at some point */

My guess is that if you can fix that "parse error", the other reported
errors will go away.

Can you spot anything there that looks like it might cause such an error ?

What version of gcc are you using ?

Straw clutch:
Could it be that line 142 needs to return a specific value ? ie maybe
'return;' needs to be replaced with 'return 0;' ... or something ...
probably worth trying (especially if you're using an antiquated version of
gcc).

Cheers,
Rob

 

[Lukas Mai]

When I look at hparser.c I can't see any way that there could be a "parse
error before `offset'" on line 145:

141: if (p_state->eof)
142: return;
143:
144: /* capture offsets */
145: STRLEN offset = p_state->offset;

I can. If you use a C89 compiler, this will give you a parse error
because declarations are only allowed at the beginning of a block. By
default gcc uses -std=gnu89 (C89 with gnu extensions) though, which
allows this. My guess is that something causes gcc to run in
-ansi/-std=c89 mode.

Hmm, or is this the first occurrence of STRLEN? It's obviously meant to
be a type, but if it's undefined, that line would be a syntax error,
too.

HTH, Lukas

 

[Sisyphus]

I can. If you use a C89 compiler, this will give you a parse error
because declarations are only allowed at the beginning of a block.

Good point - and this looks possible to me. I'm thinking that if the op is
only just now updating from perl 5.6, then there's a good chance that it's
an old compiler.

Hmm, or is this the first occurrence of STRLEN? It's obviously meant to
be a type, but if it's undefined, that line would be a syntax error,
too.

But it's a "parse error" not a "syntax error". They're different aren't they
? (That's not a smartarse rhetorical question ... I honestly don't know the
answer

Cheers,
Rob

 

[Tad McClellan]

shouldn't you be compiling with gcc on linux?

/usr/bin/cc is a symlink to /usr/bin/gcc on most (all?) linux systems.

 

[Chris]

Good point - and this looks possible to me. I'm thinking that if the op is
only just now updating from perl 5.6, then there's a good chance that it's
an old compiler.

I had considered this, and unfortunately, I think this is probably the
case, though I don't know why my compiler would be using C89. I'm
running gcc 2.95... I guess it's time to upgrade to gcc 3.x as well.
I think I tried this before and ran into issues. The real answer may
be to break down and just upgrade/reinstall a later version of Linux on
newer hardware. SuSE 8.0 is at least a couple of years old. I'm still
running a 2.4 kernel, etc.. This server has been so stable, I haven't
wanted to do it... It practically runs my household.

(Not to tangent off to an OS war, but can anyone say with a straight
face that a Windows server running on a Pentium II 400mhz would still
be functioning as this machine has? With typical multi-hundred day
uptimes? To say nothing of kinds of services it provides, which I
won't go into here since the list is long. But all this is completely
off topic; I couldn't help but mention it though I realize here in
c.l.p.m I'm only preaching to the choir.)

-ceo

 

[Sisyphus]

I had considered this, and unfortunately, I think this is probably the
case, though I don't know why my compiler would be using C89.

It shouldn't be all that hard to prove conclusively.

If that's the problem, then you should be able to fix it by (in hparser.c)
rewritng the report_event() function so that it starts like so:

static void
report_event(PSTATE* p_state,
event_id_t event,
char *beg, char *end, U32 utf8,
token_pos_t *tokens, int num_tokens,
SV* self
)
{
struct p_handler *h;
dTHX;
dSP;
AV *array;
STRLEN my_na, offset, line, column;
char *argspec;
char *s;

#ifdef UNICODE_HTML_PARSER
#define CHR_DIST(a,b) (utf8 ? utf8_distance((U8*)(a),(U8*)(b)) : (a) -
(b))
#else
#define CHR_DIST(a,b) ((a) - (b))
#endif

/* some events might still fire after a handler has signaled eof
* so suppress them here.
*/
if (p_state->eof)
return;

/* capture offsets */
offset = p_state->offset;
line = p_state->line;
column = p_state->column;

All I've done there is remove the 'STRLEN' from the last 3 lines, and add
'offset', 'line' and 'column' to the STRLEN declarations near the beginning
of the function. It still compiles fine for me .... and will hopefully
compile fine for you, too.

Cheers,
Rob

 

[Chris]

It shouldn't be all that hard to prove conclusively.

If that's the problem, then you should be able to fix it by (in hparser.c)
rewritng the report_event() function so that it starts like so:

static void
report_event(PSTATE* p_state,
event_id_t event,
char *beg, char *end, U32 utf8,
token_pos_t *tokens, int num_tokens,
SV* self
)
{
struct p_handler *h;
dTHX;
dSP;
AV *array;
STRLEN my_na, offset, line, column;
char *argspec;
char *s;

#ifdef UNICODE_HTML_PARSER
#define CHR_DIST(a,b) (utf8 ? utf8_distance((U8*)(a),(U8*)(b)) : (a) -
(b))
#else
#define CHR_DIST(a,b) ((a) - (b))
#endif

/* some events might still fire after a handler has signaled eof
* so suppress them here.
*/
if (p_state->eof)
return;

/* capture offsets */
offset = p_state->offset;
line = p_state->line;
column = p_state->column;

All I've done there is remove the 'STRLEN' from the last 3 lines, and add
'offset', 'line' and 'column' to the STRLEN declarations near the beginning
of the function. It still compiles fine for me .... and will hopefully
compile fine for you, too.

Cool, I'll give it a try and see what happens. I'm not right on top of
all this (as you can see), but it would be interesting to get resolved.

Cheers,

Indeed.

-ceo