Fedora Core 5 on x86_64 compile?

[JoshuaPrismon]

Guys,

Has anyone been able to sucessfully get Zimbra to compile on Fedora Core 5? Since there is no daily build or release build for FC5, I need to get this up to work on a new server that will be replacing my existing one.

What I have gotten to work so far is:

http://wiki.zimbra.com/index.php?tit...e_5_and_x86_64

But now I am hitting two seperate errors. The first in perdition:
gcc -shared .libs/perditiondb_daemon.o .libs/unix_socket.o -L/opt/zimbra/openldap/lib -L/opt/zimbra/lib -L/opt/zimbra/perdition-1.17/lib -L/opt/zimbra/sleepycat/lib -lpthread -ldb -L/home/Projects/Source/Zimbra/main/ThirdParty/perdition/perdition-1.17/perdition/db/daemon -lperditiondb_daemon_packet -Wl,-soname -Wl,libperditiondb_daemon.so.0 -o .libs/libperditiondb_daemon.so.0.0.0
/usr/bin/ld: skipping incompatible /opt/zimbra/lib/libdb.a when searching for -ldb
/usr/bin/ld: /home/Projects/Source/Zimbra/main/ThirdParty/perdition/perdition-1.17/perdition/db/daemon/libperditiondb_daemon_packet.a(packet.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/home/Projects/Source/Zimbra/main/ThirdParty/perdition/perdition-1.17/perdition/db/daemon/libperditiondb_daemon_packet.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

This appears to be a 32bit/64bit conflict (the DB was built from scrach). Any ideas?

[KevinH]

Might try adding -fPIC to the BDB build. We've not ran a 64bit compile so may be some makefile hacking that is needed. Also make sure you re-run configure for BDB since your on a different platform.

[JoshuaPrismon]

Originally Posted by KevinH

Might try adding -fPIC to the BDB build. We've not ran a 64bit compile so may be some makefile hacking that is needed. Also make sure you re-run configure for BDB since your on a different platform.

I already tried that unfortunitly. It didn't appear to fix the problem.

[JoshuaPrismon]

Originally Posted by lostknight

I already tried that unfortunitly. It didn't appear to fix the problem.

To be more specific I added the -fPIC to the make file. I see a config.status, but I don't see a configure or autoconf anywhere for BDB. Maybe moving to a more modern bdb?

[sdgeek]

I've had similar problems with the 'use fPIC' error that I was able to get around by exporting CFLAGS=-fPIC

There were a few places I had to modify the makefiles to put the switch in, but I'm still working at it.

Hope that helps.

[Coilcore]

I tried getting zimbra to compile on FC4 X86_64, and eventually gave up and reinstalled the OS as a 32bit version.

From what I can there are numerous cross dependancies in the version of Perl, postfix, et al that zimbra installs that are just not right for X86_64. You can start down the path of a tweak here and a tweak there, modifying this script, symlinking that file, and so on. But pretty soon you get a really scary tangled mess that makes one wonder if it was really worth it.

IMHO, the performane gain is not enough.

[dual_prophet]

Originally Posted by Coilcore

I tried getting zimbra to compile on FC4 X86_64, and eventually gave up and reinstalled the OS as a 32bit version.

From what I can there are numerous cross dependancies in the version of Perl, postfix, et al that zimbra installs that are just not right for X86_64. You can start down the path of a tweak here and a tweak there, modifying this script, symlinking that file, and so on. But pretty soon you get a really scary tangled mess that makes one wonder if it was really worth it.

IMHO, the performane gain is not enough.

This guide worked for me:

http://comptekki.googlepages.com/zimbra.html

Compiling software is a little different in x86_64, and does require some research before diving into it. I wouldn't call it a scary mess though Also, FC4 x86_64 can run both 32 and 64 bit applications with the proper libraries(usually selected during os install, but can be installed later), so you can run the standard build while working on the x86 compile. We've experienced performance gains near 165% running "64 on 64" vs "32 on 64" on the same test server, possibly because our hardware was truly 64 bit (PCI Express SATA RAID, NICs).