Patch 30180 in maint causes lots of "implicit declaration of function
'XXX'" warnings during 'make'. As a result, 'make test' produces a lot
of failures and eventually hangs (under Cygwin). Zip of log files is attached.
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.

Fri, Feb 09, 2007 at 09:01:19AM -0800, Jerry D. Hedden wrote:
Patch 30180 in maint causes lots of "implicit declaration of function
'XXX'" warnings during 'make'. As a result, 'make test' produces a lot
of failures and eventually hangs (under Cygwin). Zip of log files is attached.

Um, not good. Problem is that that's a delayed change from an earlier patch
to reentr.pl. I'm hoping that the next part of the original change that I
missed resolves it:

Change 30182 by nicholas@nicholas-saigo on 2007/02/09 18:32:16

Integrate:
[ 28898]
Subject: Re: reentr reshuffle
From: Jarkko Hietaniemi <jhi (AT) iki (DOT) fi>
Date: Thu, 28 Sep 2006 14:15:45 +0300
Message-ID: <451BAEE1.1070509 (AT) iki (DOT) fi>

Does this solve it?

Nicholas Clark

Fri, Feb 09, 2007 at 12:53:26PM -0800, Jerry D. Hedden wrote:
Jerry D. Hedden wrote:
Patch 30180 in maint causes lots of "implicit declaration of
function
'XXX'" warnings during 'make'. As a result, 'make test' produces a
lot
of failures and eventually hangs (under Cygwin). Zip of log files
is attached.

Nicholas Clark wrote:
Um, not good. Problem is that that's a delayed change from an earlier
patch
to reentr.pl. I'm hoping that the next part of the original change
that I
missed resolves it:

Change 30182 by nicholas@nicholas-saigo on 2007/02/09 18:32:16

Integrate:
[ 28898]
Subject: Re: reentr reshuffle
From: Jarkko Hietaniemi <jhi (AT) iki (DOT) fi>
Date: Thu, 28 Sep 2006 14:15:45 +0300
Message-ID: <451BAEE1.1070509 (AT) iki (DOT) fi>

Does this solve it?

Nope. Looks to be just as bad. Zip of logs attached.

K. So I'm very confused. Why didn't cygwin get upset with the same changes
on blead?

I suspect that all the test failures are from incorrect code being generated
when the compiler defaults the return type of functions to int, when it
should be types such a long long or double. So I'm hoping solving the
prototyping problem will solve the tests.

So, for example, why are strtoull and strlcpy showing as warnings here:

`sh cflags "optimize=' -pipe -funit-at-a-time -mtune=pentium4m -march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse -msse2'" util.o` util.c
CCCMD = gcc -DPERL_CRE -c -DPERL_USE_SAFE_PUTENV -DPERL_DNT_CREATE_GVSV -DNMATHMS -fno-strict-aliasing -pipe -Wdeclaration-after-statement -std=c89 -pipe -funit-at-a-time -mtune=pentium4m -march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse -msse2 -Wall -ansi -W -Wextra -Wendif-labels
util.c: In function `Perl_my_setenv':
util.c:1598: warning: implicit declaration of function `unsetenv'
util.c:1600: warning: implicit declaration of function `setenv'
util.c: In function `Perl_find_script':
util.c:3091: warning: implicit declaration of function `strlcpy'
util.c: In function `Perl_get_hash_seed':
util.c:4712: warning: implicit declaration of function `strtoull'
util.c:4719: warning: implicit declaration of function `srand48'
util.c:4720: warning: implicit declaration of function `drand48'
util.c: In function `Perl_my_snprintf':
util.c:4968: warning: implicit declaration of function `vsnprintf'

Were there warnings about implicit declaration of those two prior to change
30180?

Nicholas Clark

Fri, Feb 09, 2007 at 01:49:39PM -0800, Jerry D. Hedden wrote:
Were there warnings about implicit declaration of those two prior to
change 30180?

There were no implicit declaration with 30176 and 30179.

Thanks. I'm still confused, though. If you take the reentr.inc from the
30179 tree, and put it into the 30182 tree, does everything build without
the warnings about implicit declarations?

I *think* that it has to be something changed that file, but it would be good
to confirm that.

Nicholas Clark

Fri, Feb 09, 2007 at 04:52:13PM -0800, Jerry D. Hedden wrote:
Nicholas Clark wrote:
If you take the reentr.inc from the
30179 tree, and put it into the 30182 tree, does everything build
without the warnings about implicit declarations?

Yes. I built 30187 with reentr.inc from 30179: no warnings and all
tests succeeded.

Thanks.

That's nuts. reentr.inc doesn't even mention strtoull and strlcpy

I'm wondering what on earth the preprocessor does. I don't know if this is
the best way to try to work it out, but could you mail the pre-processed
source for something (eg run.c) for the real 30187 (or one that breaks)
and the same source with the reentr.inc from 30179 (the one that doesn't)

If Cygwin is using the Makefile from Makefile.sh then `make run.i` will do it.

Nicholas Clark

Sat, Feb 10, 2007 at 06:13:00AM -0800, Jerry D. Hedden wrote:
Nicholas Clark <nick (AT) ccl4 (DOT) orgwrote:
That's nuts. reentr.inc doesn't even mention strtoull and strlcpy

I'm wondering what on earth the preprocessor does. I don't know if
this is
the best way to try to work it out, but could you mail the
pre-processed
source for something (eg run.c) for the real 30187 (or one that
breaks)
and the same source with the reentr.inc from 30179 (the one that
doesn't)

If Cygwin is using the Makefile from Makefile.sh then `make run.i`
will do it.

Attached.

These appear to be built from unmodified 30179 and 30187 trees (rather than
a 30187 tree retrofitted with the reentr.inc from 30179), as one doesn't
have the do_ref changes removed with change 31081 - eg diff hunk:

@@ -6741,7 +6345,6 @@
I32 Perl_call_pv(register PerlInterpreter* my_perl __attribute__((unused)), const char* sub_name, I32 flags);
I32 Perl_call_sv(register PerlInterpreter* my_perl __attribute__((unused)), SV* sv, I32 flags);
void Perl_despatch_signals(register PerlInterpreter* my_perl __attribute__((unused)));
- P * Perl_doref(register PerlInterpreter* my_perl __attribute__((unused)), P *o, I32 type, char set_op_ref);
SV* Perl_eval_pv(register PerlInterpreter* my_perl __attribute__((unused)), const char* p, I32 croak_on_error);
I32 Perl_eval_sv(register PerlInterpreter* my_perl __attribute__((unused)), SV* sv, I32 flags);
SV* Perl_get_sv(register PerlInterpreter* my_perl __attribute__((unused)), const char* name, I32 create);

However, there is something else strange going on as the first difference
between the two is

run.i.30179Sat Feb 10 14:15:06 2007
run.i.30189Sat Feb 10 14:15:12 2007
@@ -455,13 +455,6 @@
int __attribute__((__cdecl__)) isxdigit(int);
int __attribute__((__cdecl__)) tolower(int);
int __attribute__((__cdecl__)) toupper(int);
-
-
-int __attribute__((__cdecl__)) isblank(int);
-int __attribute__((__cdecl__)) isascii(int);
-int __attribute__((__cdecl__)) toascii(int);
-int __attribute__((__cdecl__)) _tolower(int);
-int __attribute__((__cdecl__)) _toupper(int);
# 44 "/usr/include/ctype.h" 3 4
extern const __attribute__((dllimport)) char _ctype_[];
# 490 "perl.h" 2
@@ -1105,8 +1098,7 @@
char *mkdtemp (char *);
# 18 "/usr/include/stdlib.h" 2 3 4
-# 1 "/usr/include/alloca.h" 1 3 4
-# 20 "/usr/include/stdlib.h" 2 3 4
+

which is way way way before the first inclusion of op.h (line 3752 or so in
the preprocessed output) let alone anything to do with reentr.h or reentr.inc
So something has to be setting a "strict ANSI C" mode, when it didn't before.

The first section that differs is from ctype.h. The 30179 version looks like
this:

# 10 "/usr/include/ctype.h" 3 4
int __attribute__((__cdecl__)) isalnum(int);
int __attribute__((__cdecl__)) isalpha(int);
int __attribute__((__cdecl__)) iscntrl(int);
int __attribute__((__cdecl__)) isdigit(int);
int __attribute__((__cdecl__)) isgraph(int);
int __attribute__((__cdecl__)) islower(int);
int __attribute__((__cdecl__)) isprint(int);
int __attribute__((__cdecl__)) ispunct(int);
int __attribute__((__cdecl__)) isspace(int);
int __attribute__((__cdecl__)) isupper(int);
int __attribute__((__cdecl__)) isxdigit(int);
int __attribute__((__cdecl__)) tolower(int);
int __attribute__((__cdecl__)) toupper(int);

int __attribute__((__cdecl__)) isblank(int);

Those 3 blanks lines are lines 23-25 in /usr/include/ctype.h

What's in lines 23-25 of /usr/include/ctype.h? I assume an #ifdef?
If so, what's changed to (not) set the symbol that brings in isblank(), and
later on drand48() etc?

Are the config.sh files identical for the failing and successful builds?

Nicholas Clark

Sat, Feb 10, 2007 at 08:48:00AM -0800, Jerry D. Hedden wrote:

Nicholas Clark wrote:
These appear to be built from unmodified 30179 and 30187
trees (rather than a 30187 tree retrofitted with the
reentr.inc from 30179), as one doesn't have the do_ref
changes removed with change 31081 - eg diff hunk:

, my fault. Attached is a zip with run.i.30189 which is
from the full 30189 tree, and run.i.30189_30179 which is
from the 30189 tree that includes reentr.inc from 30179.

Thanks. They're identical. I'm confused.

Could you make doio.i for the two permutations, as it was showing errors
about undefined functions in your make log

What's in lines 23-25 of /usr/include/ctype.h? I assume an
#ifdef? If so, what's changed to (not) set the symbol
that brings in isblank(), and later on drand48() etc?

>From /usr/include/ctype.h:

21 int __cdecl tolower(int);
22 int __cdecl toupper(int);
23
24 #ifndef __STRICT_ANSI__
25 int __cdecl isblank(int);
26 int __cdecl isascii(int);

Are the config.sh files identical for the failing and
successful builds?

Yes

Most strange. It's as if something causes __STRICT_ANSI__ to get defined.

(I'm assuming that that also guards the prototypes of all the other functions
that then appear in the make error log being implicitly defined)

But I can't see how that can happen, given that the only change is reentr.inc
which doesn't mention it, and is included after /usr/include/ctype.h has
already been processed.

Nicholas Clark