The build of pythia6 changed as reported by Robert.
Between ROOT v6_12_06a and v6_16_00 there was a minor version change in the pythia6 build: root v6_12_06a -q e17:prof |__clhep v2_3_4_6 -q e17:prof | |__gcc v7_3_0 |__fftw v3_3_6_pl2 -q prof |__gsl v2_4 -q prof |__pythia v6_4_28k -q gcc730:prof |__postgresql v9_6_6a -q p2714b | |__python v2_7_14b | |__sqlite v3_20_01_00 |__mysql_client v5_5_58a -q e17 |__libxml2 v2_9_5 -q prof |__xrootd v4_8_0b -q e17:prof |__tbb v2018_2a -q e17:prof vs. root v6_16_00 -q e17:prof |__numpy v1_15_4b -q e17:p2715a:prof | |__python v2_7_15a | | |__sqlite v3_26_00_00 | |__lapack v3_8_0c -q e17:prof | |__gcc v7_3_0 |__fftw v3_3_8 -q prof |__gsl v2_5 -q prof |__pythia v6_4_28p -q gcc730:prof |__postgresql v9_6_11b -q p2715a |__mysql_client v5_5_62 -q e17 |__libxml2 v2_9_9 -q prof |__xrootd v4_8_5b -q e17:prof |__tbb v2019_3 -q e17:prof Since pythia6 has no sub-dependence it's unclear what drove this change. The `k` vs. `p` version is indicative of a change in SciSoft build and not a change in the pythia6 code itself. But it does look like the v6_4_28p version was built somehow differently ... (possibly) without all the necessary bits needed for correct integration: v6_4_28k/Linux64bit+2.6-2.12-gcc730-prof/lib/: libpydum.a libPythia6.so libpythia.a v6_4_28p/Linux64bit+2.6-2.12-gcc730-prof/lib/: libPythia6.so There might also be some odd interaction with diff -u -r -b -w v6_4_28k/source v6_4_28p/source/ Only in v6_4_28k/source/pythia: src Only in v6_4_28p/source/pythia: ssmssm.f Only in v6_4_28p/source/pythia: structm.f Only in v6_4_28p/source/pythia: structp.f Only in v6_4_28p/source/pythia: sugra.f Only in v6_4_28p/source/pythia: update_notes.txt Only in v6_4_28p/source/pythia: upevnt.f Only in v6_4_28p/source/pythia: upevnt.f.orig Only in v6_4_28p/source/pythia: upinit.f Only in v6_4_28p/source/pythia: upinit.f.orig Only in v6_4_28k/source/pythia: ups Only in v6_4_28p/source/pythia: upveto.f Only in v6_4_28p/source/pythia: upveto.f.orig Only in v6_4_28p/source/pythia: visaje.f Only in v6_4_28p/source/: tpythia6_build I think those `structm.f` and `strict.f` shouldn't be there ... internally they say: C...Dummy routine, to be removed when PDFLIB is to be linked.
Between v6_4_28k and v6_4_28p, apart from the usual minor changes to add support for new compilers, we moved from using our own spit of the source to one provided by Lund officially, request channeled via Steve Mrenna. This was done contemporaneously with the inauguration of a Spack recipe for Pythia6, to avoid FNAL being encoded forever in the upstream repository as the place to obtain the code. PYTIME, UPEVNT, UPINIT and UPVETO are now handled via patch (see https://cdcvs.fnal.gov/redmine/projects/build-framework/repository/pythia-ssi-build/revisions/master/entry/patch/pythia6.patch). We no longer produce a static library, and (so far) have had no complaints. It's possible that we missed a couple of dummies when we were dealing with the new Lund-split tarballs, but again, we have had no complaints. We can certainly meet later today and discuss specifics if you still have concerns.