Description of problem: Hercules refuses to recognize many devices, for example 3505. Version-Release number of selected component (if applicable): hercules-3.05-3.fc8 How reproducible: Synchronous Steps to Reproduce: 0. Install Fedora Rawhide, install hercules with "yum install hercules" 1. Use the attached hercules.cnf Actual results: No devices found (except FBA disks, strangely enough...) Expected results: All devices recognized Additional info: The strace shows this: write(4, "HHCCF065I Hercules: tid=2AD76E5C"..., 72) = 72 open("/hercules/hdt3505.la", O_RDONLY) = -1 ENOENT open("/hercules/hdt3505", O_RDONLY) = -1 ENOENT open("/lib/hdt3505.la", O_RDONLY) = -1 ENOENT open("/usr/lib/hdt3505.la", O_RDONLY) = -1 ENOENT open("hdt3505.la", O_RDONLY) = -1 ENOENT access("/lib/hdt3505", R_OK) = -1 ENOENT access("/usr/lib/hdt3505", R_OK) = -1 ENOENT open("/etc/ld.so.cache", O_RDONLY) = 10 fstat(10, {st_mode=S_IFREG|0644, st_size=84779, ...}) = 0 mmap(NULL, 84779, PROT_READ, MAP_PRIVATE, 10, 0) = 0x2aaaaf55b000 close(10) = 0 open("/lib64/tls/hdt3505", O_RDONLY) = -1 ENOENT open("/lib64/hdt3505", O_RDONLY) = -1 ENOENT open("/usr/lib64/tls/hdt3505", O_RDONLY) = -1 ENOENT open("/usr/lib64/hdt3505", O_RDONLY) = -1 ENOENT munmap(0x2aaaaf55b000, 84779) = 0 write(4, "HHCCF042E Device type 3505 not r"..., 42) = 42 But this is utterly insane, the modules are *.so here: [zaitcev@niphredil ~]$ ls /usr/lib64/hercules/ dyncrypt.so hdt1052c.so hdt2880.so hdt3420.so hdteq.so dyngui.so hdt1403.so hdt3088.so hdt3505.so hdtqeth.so dyninst.so hdt2703.so hdt3270.so hdt3525.so [zaitcev@niphredil ~]$ Side note: I don't understand why Hercules needs the dynamic load capability, the whole directory is 240K together with all symbol tables and everything. I would just link everything statically and avoid all this mess with libtool completely. I don't know what Jay was thinking here.
Created attachment 293339 [details] hercules.cnf
This is not the first 64bit specific problem reported with hercules... and I wouldn't be surprised if this problem was actually created by one of the "workarounds" to get the package to build. I'll have a quick look at it now. See bugs #158449 and especially #185906.
Looks like the sources use autotools in a strange way. Both configure.ac and Makefile.am are quite short, and I'm pretty sure the problem lies there, possibly also because of some of the hacks in the spec file. In configure.ac : The whole DESTPREFIX hack seems useless, as using DESTDIR it should be possible to achieve the same thing in a clean way. In Makefile.am : Again, lots of stuff looks useless to me, but I'm not autotools literate enough to know how to clean it up. CC'ing Hans, who's my personal bug squashing hero :-) Hans : Could you have a quick look at this if you have a moment? (now that I come to think of it, this is weird, though, since I've used hercules quite a few times on x86_64 myself, although possibly some older version on an older Fedora release)
Here is an initial hint, ./configure says: configure: configure: Package destination directory prefixes: configure: configure: Libraries: /hercules configure: Data: /usr/share/hercules configure: Locale: /usr/share/locale configure: Look at Libraries dir! Investigating further.
Further clues: checking which extension is used for loadable modules... checking which variable specifies run-time library path... LD_LIBRARY_PATH checking for the default library search path... /lib /usr/lib Note that according to ./configure, there is no extension which is used for loadable modules..., where as the answer should be: ".so" Also note the default library search path... /lib /usr/lib, on my x86_64. Not that having this correct would help in any way, as the libs are not in the default path, but are under: /usr/lib64/hercules So there are 2 problems, both if which are fatal by itself: 1) configure does not set MODULESDIR correctly in config.h . It gets set to /hercules instead of to $(libdir}/hercules. Since the modules are under $(libdir}/hercules, which is not part of any default search path's this bug is fatal. I don't see anyway this could work on i386 so, so I don't agree with comment 2 that this is 64 bit specific issue. To be sure I've also checked this on i386 and indeed there the same bug exists. 2) configure does not set LTDL_SHLIB_EXT to ".so" in config.h, therefor the plugins will only get found if their resp. .la files also are installed. Again this is not 64 bit specific. I'm working on a patch I'll attach that shortly.
Created attachment 293836 [details] spec patch fixing this bug As promised a patch fixing this. Notice that the not proper setting of the MODULESPATH was due to some error in the perl search replace on configure*. But that alone does not explain this bug, as the not detecting of the .so extension is a problem too.
Hans, thanks a lot! The patch fixes the problem. Do you think we ought to add sed to BuildRequires? BTW, the RPM build aborts with this: Checking for unpackaged file(s): /usr/lib/rpm/check-files /q/tmp/hercules-3.05-4.fc9-root error: Installed (but unpackaged) file(s) found: /usr/lib64/libdecNumber.a
(In reply to comment #7) > Hans, thanks a lot! The patch fixes the problem. > Good to hear. > Do you think we ought to add sed to BuildRequires? > Nope, we have a zillion .spec files using sed without any of them explicitly requiring it. > BTW, the RPM build aborts with this: > > Checking for unpackaged file(s): /usr/lib/rpm/check-files > /q/tmp/hercules-3.05-4.fc9-root > error: Installed (but unpackaged) file(s) found: > /usr/lib64/libdecNumber.a > Strange it build fine for me.
Built fine for me, and in koji too. Thanks a lot Hans! :-) Pete : Please try the latest devel package.
Fixed in 3.05-4.fc9.