Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 460706

Summary:	Running 32 bit (i386) broker on 64 bit system (x86_64) will fail to correctly find and load modules
Product:	Red Hat Enterprise MRG	Reporter:	Andrew Stitcher <astitcher>
Component:	qpid-cpp	Assignee:	messaging-bugs <messaging-bugs>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Kim van der Riet <kim.vdriet>
Severity:	high	Docs Contact:
Priority:	medium
Version:	1.0
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andrew Stitcher 2008-08-29 22:25:20 UTC

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008071615 Fedora/3.0.1-1.fc9 Firefox/3.0.1

[From code inspection]
The default module load location id calculated dynamically based in the platform the broker is running on NOT the type of executable that is running.

This means that a i386 broker running on an x86_64 installation which is perfectly valid (and should be correctly supported) will try to load modules from /usr/lib64/qpidd which will either not contain any modules (if the 64 bit qpidd isn't installed) or will find modules that cannot be loaded (due to wrong architecture) if it is.

The probably fix is to calculate the default module directory at build time (which knows the architecture its building) and not try to calculate at run time.

Reproducible: Always

Steps to Reproduce:
Not observed - bug found from code inspection:

But installing an i386 qpidc/rhm on an x86_64 box should exhibit this bug.
Actual Results:  
I expect that running an i386 qpidd with an bdbstore module will fail to work with the default module directory on an x86_64 machine

Comment 1 Andrew Stitcher 2009-02-05 16:29:39 UTC

This has been fixed as of qpidd r694113