Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: /usr/obj/gnu/lib/libiberty/libiberty.a: could not read symbols: Bad value



In article <20081017180113.GA1034%panix.com@localhost>,
Thor Lancelot Simon  <tls%rek.tjls.com@localhost> wrote:
>On Fri, Oct 17, 2008 at 05:24:40PM +0000, Christos Zoulas wrote:
>> In article <48F8C8A4.9080003%NetBSD.org@localhost>, Elad Efrat 
><elad%NetBSD.org@localhost> wrote:
>> >Hi,
>> >
>> >I get that too. It's another issue with MKPIE=yes builds.
>> 
>> Well, it should be linking against libiberty_pic.a ... I don't think that
>> making libiberty.a PIC is a good idea. Or just create libiberty.so and
>> be done with it.
>
>This is a persistent problem with MKPIE: things are generated as PIC
>inappropriately instead of linking other things against already-existing
>PIC or shared versions of the same objects.
>
>It is a fairly thorny Makefile problem because you have to somehow _know_
>that the linker won't find foo.so and will try to use foo.a, so that you
>can then change the library name supplied to the linker to foo_pic so that
>it picks up foo_pic.a.
>
>Can anyone think of an elegant way to solve this?

When you have -fpie you look in libfoo_pic.a not libfoo.a, but what
about profiling? Do you provide libfoo_pic_p.a?

For now I have made all .a archives PIC when MKPIE is set.

christos



Home | Main Index | Thread Index | Old Index