[Digikam-devel] Can't compile 0.8beta2

[Anssi Hannula]

Andy Choens wrote:
> I have tried everything I know of to compile beta2, and I can't.  I'm
> sure it's something really obvious, but it's kicking my butt.
> 
> I'm running SUSE 10 on an amd64.  If I can get it to compile, I'll put
> together a package and contribute it for distribution.  That would be
> really neat.
> 
> On my system, KDE is in /opt/kde3 and I obviously have 32bit and 64bit
> libraries installed.
> 
> I followed the direction in the README and did this.
> 
> export WANT_AUTOCONF_2_5=1
> export KDEDIR=/opt/kde3
> make -f Makefile.cvs
> ./configure
> make
> 
> and that's as far as I got.  It compiles along for a couple of minutes
> just fine, and then I get this output:
> 
> /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
> ../../digikam/utilities/setup/.libs/libsetup.a(setupgeneral.o):
> relocation R_X86_64_PC32 against `QDir::operator!=(QDir const&) const'
> can not be used when making a shared object; recompile with -fPIC
> /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
> final link failed: Bad value
> collect2: ld returned 1 exit status
> make[4]: *** [libdigikam.la] Error 1
> make[4]: Leaving directory
> `/home/andy/errata/compile/digikam-0.8.0-beta2/digikam/digikam'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory
> `/home/andy/errata/compile/digikam-0.8.0-beta2/digikam/digikam'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> `/home/andy/errata/compile/digikam-0.8.0-beta2/digikam'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/andy/errata/compile/digikam-0.8.0-beta2'
> make: *** [all] Error 2
> 
> 
> I think I've included all of the important stuff.
> 
> If anyone has any ideas, I'd love to try them out, and I'll certainly
> contribute a package for amd64 and I'll see if I can figure out how to
> compile for 32bit SUSE too.

There is a similar problem in Mandriva:
http://qa.mandriva.com/show_bug.cgi?id=18984

Welvaart has found 3 solutions:
a) build that setupgeneral.o without -fvisibility-inlines-hidden
b) explicitly set the visibility of the method to "default" in qdir.h
(using Q_EXPORT)
c) gcc patch to give an explicit class visibility declaration higher
precedence than a global (commandline) -fvisibility-inlines-hidden
option: http://qa.mandriva.com/attachment.cgi?id=3772

What do the you think? Where is the bug, in gcc?

-- 
Anssi Hannula