develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About