Re: Smoke [ebcdic] v5.23.4-165-g4d9f9c0 FAIL(M) os/390 24.00 (2964/)

On 11/19/2015 05:59 PM, Karl Williamson wrote:
> We still have the failure to build.  My changes got rid of the unclosed
> #if errors, but that didn't fix the compilation failures.  They look
> like this:
>
> Can't find 'boot_re' symbol in lib/auto/re/re.so
>   at lib/re.pm line 88.
>
> This had been showing up in the logs besides the unclosed #if, but I
> figured that that error could have caused this one as well.  But now,
> that one is gone, and this remains, so there is something else going wrong.
>
> Since my changes beyond blead being tested here differ only in minor
> tweaks from what had worked before, I have started to suspect that
> perhaps the problem wasn't my changes, but something that had happened
> in blead recently.
>
> Fortunately, you had just tested plain blead, and it worked:
>
> Smoke [blead] v5.23.4-94-g6cae08a PASS os/390 24.00 (2964/
>
> I examined the changes in blead between this one that passed, and the
> first failure.  There are only about a dozen commits.  If you had git on
> your system, we could do an automatic bisect in fairly short order.  The
> other option generally available is to do a manual bisect to find the
> real culprit.  But in examining these dozen or so commits, almost half
> (5 of them) involved DynaLoader, and that is the module responsible for
> getting that 'boot_re' symbol.  Looking at the other commits, they
> appear to me to be less likely to affect this.  So suspicion naturally
> falls on those 5.  So what I've done is to push a new branch to test,
> with the 5 reverted.  I think it is fairly likely that it will not have
> the current failure.  If I'm right, we can get their author to
> investigate further, and we've saved some effort by not having to do a
> blind manual bisect.  If I'm wrong, then it's something else.
>
> So, if this branch still fails with the boot_re problem, we know its not
> the DynaLoader changes.  Please then go ahead and test current blead
> without waiting for any new branch from me.  If that works, then we know
> it's something I did, and I'll have to figure that out.  If it doesn't
> work, then it's almost certainly one of those 7 or so other commits and
> we can revert some of those to find which one is at fault, and go on
> from there.

I also got some advice from bulk88 in tracking this down which I'm 
passing on as-is:

"look at re.c on the os390 build, is XS_EXTERNAL(boot_re) there?
next step is search the .o files for the symbol
then nm or objdump the .so
the preprocessed .i file between re.c and re.o is another place to check
the question is, where in the build process did the symbol disappear?
xsubpp could have forgotten to write a boot xsub
the boot xsub might be disabled with CPP defines
the def file (if platform appropriate, aka Win32) might eb screwed up, 
especially if the export list was changed from makefile.PL (it doesn't 
look to be that way from re/makefile.pl)
Can't find 'boot_re' symbol in lib/auto/re/re.so at lib/re.pm line 88.
Compilation failed in require at lib/Text/Wrap.pm line 58.
	BEGIN failed--compilation aborted at lib/Text/Wrap.pm line 58.
	Compilation failed in require at pod/buildtoc line 7.
	BEGIN failed--compilation aborted at pod/buildtoc line 7.
	make: *** [pod/perltoc.pod] Error 255
	Unable to make anything but miniperl in this configuration
that could also be a @INC problem, or a PERL_CORE env var problem that 
leads to a messe dup @INC
if the .so was from a different perl build or a different CC, name 
mangling, which is invisible on a superifical level, might be different 
internally, so "boot_re" != "boot_re"
missing symbol errors are fixed by analyzing each step of .xs -> 
.so/.dll -> .so/.dll memory mapped into perl process
freezing the process (as simple as block on STDIN), then getting a dump 
of the VM allocations in the process, which will list every .so/.dll in 
the process is a standard thing I do
pwd when starting perl core .t and .pl files is usually important, many 
.t and .pl have if( -d 't') {chdir('..');} so fi they are started with 
the wrong pwd they escape the source tree and pick up system perls and 
system perl @INCs"

>
> On 11/18/2015 11:40 PM, Yaroslav Kuzmin wrote:
>>
>> Automated smoke report for branch ebcdic 5.23.5 patch
>> 4d9f9c0de70352f49626dd8189478d5e490fea8c
>> v5.23.4-165-g4d9f9c0
>> RS12: 2964 (2964/)
>>      on        os/390 - 24.00
>>      using     c99 version
>>      smoketime 53 minutes 53 seconds (average 26 minutes 56 seconds)
>>
>> Summary: FAIL(M)
>>
>> O = OK  F = Failure(s), extended report at the bottom
>> X = Failure(s) under TEST but not under harness
>> ? = still running or test results not (yet) available
>> Build failures during:       - = unknown or N/A
>> c = Configure, m = make, M = make (after miniperl), t = make test-prep
>>
>> v5.23.4-165-g4d9f9c0  Configuration (common) none
>> ----------- ---------------------------------------------------------
>> M - M -     -Dusedl
>>>>> +----- PERLIO = perlio -DDEBUGGING
>>>> +------- PERLIO = stdio  -DDEBUGGING
>>> +--------- PERLIO = perlio
>> +----------- PERLIO = stdio
>>
>>
>> Locally applied patches:
>>      SMOKE4d9f9c0de70352f49626dd8189478d5e490fea8c
>>
>> Tests skipped on user request:
>>      # One test name on a line
>> Compiler messages(os390):
>>
>>
>>
>> --
>> Report by Test::Smoke v1.6 running on perl 5.22.0
>> (Reporter v0.052 / Smoker v0.045)
>>
>>
>> --
>> Regards,
>>
>> Yaroslav Kuzmin
>> Developer C/C++ ,z/OS , Linux
>> 3 Zhukovskiy Street · Miass, Chelyabinsk region 456318 · Russia
>> Tel:  +7.922.2.38.33.38
>> Email: [email protected]
>> Web: www.rocketsoftware.com
>> ================================
>> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
>> 02451 ■ +1 800.966.3270 ■ +1 781.577.4321
>> Unsubscribe From Commercial Email – [email protected]
>> Manage Your Subscription Preferences -
>> http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
>>
>> Privacy Policy -
>> http://www.rocketsoftware.com/company/legal/privacy-policy
>> ================================
>>
>> This communication and any attachments may contain confidential
>> information of Rocket Software, Inc. All unauthorized use, disclosure
>> or distribution is prohibited. If you are not the intended recipient,
>> please notify Rocket Software immediately and destroy all copies of
>> this communication. Thank you.
>>
>
>