Front page | perl.perl5.porters |
Postings from September 2010
Re: Smoke [5.13.5] v5.13.5-208-gdfa4c01 FAIL(M) openvms V8.3-1H1(IA64/2 cpu)
Thread Previous
From:
Craig A. Berry
Date:
September 28, 2010 21:02
Subject:
Re: Smoke [5.13.5] v5.13.5-208-gdfa4c01 FAIL(M) openvms V8.3-1H1(IA64/2 cpu)
Message ID:
E9815530-FFA8-4AA2-A92F-29C3F43E53EA@mac.com
On Sep 27, 2010, at 10:55 PM, Nicholas Clark wrote:
> On Mon, Sep 27, 2010 at 10:42:41PM -0500, Craig A. Berry wrote:
>> On Mon, Sep 27, 2010 at 8:48 PM, Craig A. Berry
>> <craigberry@mac.com> wrote:
>>> Automated smoke report for 5.13.5 patch
>>> dfa4c01391ec1a67cfb0dc8a74a065632a21242e v5.13.5-208-gdfa4c01
>>> ALMA: HP rx2600 (1.50GHz/6.0MB) (IA64/2 cpu)
>>> on openvms - V8.3-1H1
>>> using ? CC/DECC version 70390019
>>> smoketime 1 hour 39 minutes (average 49 minutes 52 seconds)
>
>>> M
>>> M -Duseithreads
>>> | +--------- -DDEBUGGING
>>> +----------- no debugging
>>
>>
>> This is caused by
>>
>> Link /NoTrace/NoMap/Share=PERLSHR.EXE DynaLoader.obj,
>> []perlshr_bld.opt/Option, perlshr_attr.opt/Option
>> %ILINK-W-NUDFSYMS, 2 undefined symbols:
>> %ILINK-I-UDFSYM, PERL_PP_AVALUES
>> %ILINK-I-UDFSYM, PERL_PP_SAY
>> %ILINK-W-USEUNDEFSYMV, undefined symbol PERL_PP_AVALUES referenced
>> in symbol vector option
>> %ILINK-W-USEUNDEFSYMV, undefined symbol PERL_PP_SAY referenced
>> in symbol vector option
>>
>>
>> I don't see any Perl_pp_avalues or Perl_pp_say functions in *.c, nor
>> do I see them documented anywhere. Am I missing something or should
>> these not actually be in proto.h?
>
> Well, prior to a4e744802906bbf8 there were prototypes for them in
> pp_proto.h
> (instead) and that built. Hence I'm confused.
Me too. Comparing the linker options files from before and after that
change, it appears that there are now lots of Perl_ck_xxx and
Perl_pp_xxx functions that were not getting exported before. Which
means they must never be called from outside of perlshr.exe (the
libperl equivalent) or something would have blown up previously. So
assuming those are all supposed to be exported, it looks like you
inadvertently fixed a gigantic bug.
I think the reason they were not getting exported has something to do
with this little snippet from vms/gen_shrfls.pl, where we root through
preprocessor output to get a list of what symbols we should be
exporting:
while (/^#.*opcode\.h/i .. /^#.*perl\.h/i) {
print "opcode.h>> $_" if $debug > 2;
if (/^OP \*\s/) { &scan_func($_); }
if (/^\s*EXT(CONST|\s+)/) { &scan_var($_); }
last LINE unless defined($_ = <CPP>);
}
but what exactly prevented this from finding those symbols in
pp_proto.h as included by proto.h as included by perl.h but it can
find them with one less level of include nesting I don't know and
haven't had time to debug.
> (pp_say is actually implemented by pp_print, pp_avalues by pp_akeys.
> If you look at the top of opcode.pl there are loads and loads of
> similar
> aliases - why are these two "special" and troublesome?)
Aha, thanks. What's special is that they don't actually exist
anywhere. Most (probably all) of the other aliased routines do exist
in mathoms.c.
So the remaining problem is excluding aliases from the list of
exported functions when there is no actual function. Not sure how
well I'll be able to generalize that but it should be easy enough to
add the two bothersome ones to the list of names to exclude.
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
Thread Previous