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: ykuz...@rocketsoftware.com
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 – unsubscr...@rocketsoftware.com
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.
