Red Hat Bugzilla – Bug 313231
Unable to link against libhspell
Last modified: 2008-10-27 18:54:34 EDT
Description of problem:
unable to link against libhspell
Version-Release number of selected component (if applicable):
hspell-devel x86_64 1.0-6.fc7
Steps to Reproduce:
1.try to compile kde4
Linking CXX shared module ../../../lib/kspell_hspell.so
/usr/bin/ld: /usr/lib64/libhspell.a(gimatria.o): relocation R_X86_64_32S
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
/usr/lib64/libhspell.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [lib/kspell_hspell.so] Error 1
On some systems (I believe i386 isn't one of these, but maybe "x86_64" is?), for
code to be in a shared library it needs to be compiled as "position independent
code", with the "-fPIC" parameter.
We can give two kinds of replies to this bug report.
The first is "this is not a bug" - libhspell.a is not position-independent-code,
and was not meant for inclusion in a shared library. kspell_hspell.so (whatever
that is) can use libhspell.a but cannot include it, and the program using this
library will need to statically link with libhspell.a
The second kind of reply is that this *is* a problem, because presumably
kspell_hspell.so is some sort of plug in that can come instead of
kspell_english.so (or whatever) at run-time, and we cannot ask the compilation
to also include libhspell.a. So in this sense, it might make sense to solve this
problem. And I can see two ways to do this. One is to continue creating an
archive (libhspell.a), just compile the individual source files with -fPIC (if
configure finds that such an option is available - usually in gcc).
The second way is to use libtool (for example) and create a full-fleged share
library in a portable way.
There's a patch in hspell's bugzilla to do these things. However, I want to
avoid using "automake" at all cost (I personally think it's a redundant tool),
and would rather use -fPIC and/or libtool directly.
There's a small performance penalty for the resulting code compiled with -fPIC
(reportedly, around 5%) but it's negligable.
I just hit this while trying to package KDE 4.0 Beta 3. I had to drop the
I disagree about this not being a bug:
1. packages shouldn't ship static libraries only in the first place and
2. if they do, the static library MUST be compiled with -fPIC, or both
PIC/non-PIC versions be provided, there's no way around it, and this bug is
pardon my ignorance, but would adding something brutal like
gcc -shared -o libhspell.so dict_radix.o gimatria.o corlist.o libhspell.o
to the spec file suffice? (and make with CFLAGS="-O2 -fPIC")
*** Bug 430354 has been marked as a duplicate of this bug. ***
There's a quick-and-dirty-hack suggestion in 430354 FWIW. enchant's hspell
integration suffers from the same problem now also.
*** Bug 189233 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Not fixed yet, bumping.
Created attachment 305374 [details]
this would work I reckon
I see that a fix was committed on May 14 (version 1.0-9), but never actually got built (Rawhide has only 1.0-8.fc9), can this be built?
Then support for hspell could also be reenabled in enchant. However, it should be an optional enchant-hspell subpackage, just like aspell and voikko.
As for KDE, I think linking KDE directly against hspell is not useful if it's supported through enchant. Sonnet (KDE's spellchecking code) uses enchant for a reason.
should be available now ( ftp://alviss.et.tudelft.nl/pub/fedora/linux/development/i386/os/Packages/hspell-devel-1.0-11.fc10.i386.rpm )