On Feb 18, 2008 10:49 AM, Paulo Cavalcanti <promac@xxxxxxxxx> wrote:
In fact, I forgot to mention that I used binutils 2.18.50 from developments.
Taking a close look at the spec file, I realized that it is possible to recompile just libbfd.a
with -fPIC, the same way it was done with libiberty.a.
Here is the .src.rpm I used:
http://people.atrpms.net/~pcavalcanti/srpms/binutils-2.18.50.0.3-1.src.rpm
Please, can someone tell me if there is any problem of using this modified binutils
in F8?
Thanks.
-- I have also encountered this, but have not fixed it yet. Any
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libbfd.a(format.o):
> relocation R_X86_64_32 against `a local symbol' can not be used when making
> a shared object; recompile with -fPIC
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libbfd.a:
> could not read symbols: Bad value
> collect2: ld returned 1 exit status
suggestions would be much appreciated.
Well, I fixed it. It is just a question of recompiling binutils with -fPIC.
I just changed this line in binutils spec file and rebuilt it:
CC="gcc -L`pwd`/bfd/.libs/" CFLAGS="${CFLAGS:-%optflags -fPIC}" ../configure \
Doing that, anjuta can be built with valgrind support in x86_64 architectures.
Note that I do not know whether this is acceptable by Fedora standards or not.
Any comments?
In fact, I forgot to mention that I used binutils 2.18.50 from developments.
Taking a close look at the spec file, I realized that it is possible to recompile just libbfd.a
with -fPIC, the same way it was done with libiberty.a.
Here is the .src.rpm I used:
http://people.atrpms.net/~pcavalcanti/srpms/binutils-2.18.50.0.3-1.src.rpm
Please, can someone tell me if there is any problem of using this modified binutils
in F8?
Thanks.
Paulo Roma Cavalcanti
LCG - UFRJ
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
