A couple of symlinks are missing leading to HHCCF042E complaints at emulator startup: ============ $ hercules conf/smp1.cnf (...) HHCHD018I Loadable module directory is /usr/lib64/hercules HHCCF065I Hercules: tid=7FF6D0A49740, pid=27713, pgid=27713, priority=0 HHCCF042E Device type 3420 not recognized HHCCF042E Device type 1403 not recognized HHCCF042E Device type 3505 not recognized HHCCF042E Device type 3525 not recognized HHCCF042E Device type 3215 not recognized HHCDA020I dasd/start1.3330 cyls=411 heads=19 tracks=7809 trklen=13312 HHCDA020I dasd/spool0.3330 cyls=411 heads=19 tracks=7809 trklen=13312 HHCCP002I CPU0000 thread started: tid=7FF6D0144700, pid=27713, priority=15 HHCTT002I Timer thread started: tid=7FF6CBFFF700, pid=27713, priority=0 HHCCP003I CPU0000 architecture mode S/370 HHCPN001I Control panel thread started: tid=7FF6D0A49740, pid=27713 HHCAO001I Hercules Automatic Operator thread started; tid=7FF6CBC63700, pri=0, pid=27713 ============ The fix is trivial: for every shared object file (i.e. '.so' file) located within in the Hercules modules directory, create a corresponding symlink having the exact basename and *no extension*. I.e.: $ ls -l /usr/lib64/hercules total 373 lrwxrwxrwx 1 root root 11 Apr 26 15:34 dyncrypt -> dyncrypt.so -rwxr-xr-x 1 root root 172072 Apr 26 14:12 dyncrypt.so lrwxrwxrwx 1 root root 9 Apr 26 15:34 dyngui -> dyngui.so -rwxr-xr-x 1 root root 34976 Apr 26 14:12 dyngui.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 dyninst -> dyninst.so -rwxr-xr-x 1 root root 14176 Apr 26 14:12 dyninst.so lrwxrwxrwx 1 root root 11 Apr 26 15:34 hdt1052c -> hdt1052c.so -rwxr-xr-x 1 root root 14656 Apr 26 14:12 hdt1052c.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdt1403 -> hdt1403.so -rwxr-xr-x 1 root root 35616 Apr 26 14:12 hdt1403.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdt2703 -> hdt2703.so -rwxr-xr-x 1 root root 49240 Apr 26 14:12 hdt2703.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdt2880 -> hdt2880.so -rwxr-xr-x 1 root root 14272 Apr 26 14:12 hdt2880.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdt3088 -> hdt3088.so -rwxr-xr-x 1 root root 86744 Apr 26 14:12 hdt3088.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdt3270 -> hdt3270.so -rwxr-xr-x 1 root root 44696 Apr 26 14:12 hdt3270.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdt3420 -> hdt3420.so -rwxr-xr-x 1 root root 110000 Apr 26 14:12 hdt3420.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdt3505 -> hdt3505.so -rwxr-xr-x 1 root root 31136 Apr 26 14:12 hdt3505.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdt3525 -> hdt3525.so -rwxr-xr-x 1 root root 14368 Apr 26 14:12 hdt3525.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdt3705 -> hdt3705.so -rwxr-xr-x 1 root root 35896 Apr 26 14:12 hdt3705.so lrwxrwxrwx 1 root root 8 Apr 26 15:34 hdteq -> hdteq.so -rwxr-xr-x 1 root root 14584 Apr 26 14:12 hdteq.so lrwxrwxrwx 1 root root 10 Apr 26 15:34 hdtqeth -> hdtqeth.so -rwxr-xr-x 1 root root 14304 Apr 26 14:12 hdtqeth.so Once this is done, HHCCF042E complaints disappear and every needed device is found. Not tested with the ebuild for Hercules 3.11 which is also present in portage.
(In reply to Adrien Dessemond from comment #0) > Not tested with the ebuild for Hercules 3.11 which is also present in > portage. Sorry my mistake, 3.11 is not here but 3.10 and 3.12 are, as of today.
Created attachment 635558 [details] Proposed ebuild for Hercules 3.13 with correct symlinks creation This one creates all of the needed symlinks for Hercules dynamic libraries at the post-installation phase.
Created attachment 635560 [details, diff] Patch for hercules-3.13.ebuild This patch applied to hercules-3.13.ebuild gives the full -r1 ebuild also attached to bug #720342.
(In reply to Adrien Dessemond from comment #3) > Created attachment 635560 [details, diff] [details, diff] > Patch for hercules-3.13.ebuild > > This patch applied to hercules-3.13.ebuild gives the full -r1 ebuild also > attached to bug #720342. I'm sorry to be a pain but could you include the GCO sign off [0] in a comment? [0] https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin
I would be happy to do so, but it is not pushed in any Git repository :) However if putting my name inside the ebuild as a contributor I will do that.
(In reply to Adrien Dessemond from comment #5) > I would be happy to do so, but it is not pushed in any Git repository :) > However if putting my name inside the ebuild as a contributor I will do > that. A comment is fine too here, signed-off-by: real name <email>.
this is because the new ebuild deletes all the .la files even though hercules explicitly uses libltdl. the .la files for modules are still needed.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0fa2a867cc1298a4c0cd3babab783072d2f6e102 commit 0fa2a867cc1298a4c0cd3babab783072d2f6e102 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2021-11-18 07:55:40 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-11-18 07:59:47 +0000 app-emulation/hercules: do not delete libtool module .la files #720342 Since hercules uses libltdl to load its internal modules, we need to leave the .la files in place for it to process. Also add subslot linkage to these libs while we're updating. Bug: https://bugs.gentoo.org/252716 Closes: https://bugs.gentoo.org/720342 Signed-off-by: Mike Frysinger <vapier@gentoo.org> .../{hercules-3.13.ebuild => hercules-3.13-r1.ebuild} | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
