Bug 430805 - Dynamic modules not found
Dynamic modules not found
Product: Fedora
Classification: Fedora
Component: hercules (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-01-29 15:57 EST by Pete Zaitcev
Modified: 2008-02-04 16:18 EST (History)
1 user (show)

See Also:
Fixed In Version: 3.05-4.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-04 16:18:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
hercules.cnf (1.47 KB, text/plain)
2008-01-29 15:57 EST, Pete Zaitcev
no flags Details
spec patch fixing this bug (1.48 KB, patch)
2008-02-03 11:00 EST, Hans de Goede
no flags Details | Diff

  None (edit)
Description Pete Zaitcev 2008-01-29 15:57:04 EST
Description of problem:

Hercules refuses to recognize many devices, for example 3505.

Version-Release number of selected component (if applicable):


How reproducible:


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.
Comment 1 Pete Zaitcev 2008-01-29 15:57:04 EST
Created attachment 293339 [details]
Comment 2 Matthias Saou 2008-02-03 07:36:21 EST
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.
Comment 3 Matthias Saou 2008-02-03 07:59:02 EST
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)
Comment 4 Hans de Goede 2008-02-03 09:27:15 EST
Here is an initial hint, ./configure says:

configure:  Package destination directory prefixes:
configure:     Libraries:  /hercules
configure:     Data:       /usr/share/hercules
configure:     Locale:     /usr/share/locale

Look at Libraries dir!

Investigating further.
Comment 5 Hans de Goede 2008-02-03 10:33:29 EST
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.
Comment 6 Hans de Goede 2008-02-03 11:00:11 EST
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.
Comment 7 Pete Zaitcev 2008-02-03 15:04:08 EST
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
error: Installed (but unpackaged) file(s) found:
Comment 8 Hans de Goede 2008-02-03 15:11:16 EST
(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.
Comment 9 Matthias Saou 2008-02-04 03:09:43 EST
Built fine for me, and in koji too. Thanks a lot Hans! :-)
Pete : Please try the latest devel package.
Comment 10 Pete Zaitcev 2008-02-04 16:18:03 EST
Fixed in 3.05-4.fc9.

Note You need to log in before you can comment on or make changes to this bug.