Bug 278901

Summary:	build problem on 64 bit architectures with evolution28
Product:	Red Hat Enterprise Linux 4	Reporter:	Martin Kočí <mkoci>
Component:	evolution	Assignee:	Matthew Barnes <mbarnes>
Status:	CLOSED DUPLICATE	QA Contact:	desktop-bugs <desktop-bugs>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4.5
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-09-20 13:57:13 UTC	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 Martin Kočí 2007-09-05 17:40:05 UTC

Description of problem:
If is on 64 bit system installed package with two versions (32bit and 64bit) and
you try to rebuilding evolution28 and building process needs some library from
that (32/64bit) package, than building process try first load library from 32
bit package and then fail with error that library is not compatible.

Version-Release number of selected component (if applicable):
evolution28 on RHEL4 64bit architectures

How reproducible:
Try to rebuild evolution28 on 64bit architecture where 32bit/64bit packages
dependences installed are. (eg. popt package)

Actual results:
Rebuilding failed.

Expected results:
Building process should try to load from both packages (32 bit and 64 bit too).

Additional info:
I haven't tested it on RHEL5.

Comment 1 Matthew Barnes 2007-09-05 18:04:41 UTC

Can you please post a build log that shows the errors you're getting?

Comment 2 Martin Kočí 2007-09-06 08:41:16 UTC

OK, Mail sent.

Comment 3 Matthew Barnes 2007-09-17 15:03:47 UTC

This seems to be the problem:

  gcc -shared  .libs/e-book-backend-file.o ... /usr/lib/libpopt.so ...
  ...
  /usr/lib/libpopt.so: could not read symbols: File in wrong format

Every other instance of libpopt.so in the build log shows up as
/usr/lib64/libpopt.so.  I have no idea why this case is different.  E-D-S
doesn't even use libopt; it get pulled into the linker command through pkgconfig
dependencies (probably from libgnome).

Does the original RHEL4 Evolution package (version 2.0.2) build under these
conditions?

Comment 4 Matthew Barnes 2007-09-17 16:05:07 UTC

I owe halfline a cookie.  He recognized this as an old bug in libtool and
suggested a workaround:

   Add "libtoolize --force" before the %configure line in the spec file.

I don't have a means of testing this for myself.  Do you think you could try
building with this workaround while I collect the necessary flags for this bug?

Comment 5 Martin Kočí 2007-09-18 09:00:41 UTC

OK I will try build it.

Comment 7 Matthew Barnes 2007-09-20 13:54:11 UTC

I think just to keep things in one place I'm going to merge this bug into bug
#251394, which already has all the necessary ACKs and blessings and what not...

Comment 8 Matthew Barnes 2007-09-20 13:57:13 UTC


*** This bug has been marked as a duplicate of 251394 ***