tech-toolchain 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
On Fri, Oct 17, 2008 at 06:03:57PM +0000, Christos Zoulas wrote:
> In article <20081017180113.GA1034%panix.com@localhost>,
> Thor Lancelot Simon <tls%rek.tjls.com@localhost> wrote:
> >
> >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?
Will it be enough to adjust only the compiler, or will we have to whack
the linker as well? The problem is you want to use foo.so (preferentially
unless -static is set) or foo_pic.a whereas without MKPIE you want foo.so
or foo.a. The change in library name rather than use of a different
extension or some kind of library properties is irritating (sigh).
> For now I have made all .a archives PIC when MKPIE is set.
This seems like a bad idea to me. It doesn't fix the case where one
wants to build only part of the system with MKPIE=yes and it costs
performance for anything that is not built PIE if all the libraries are
linked this way; plus we *already have* the PIC libraries...
I don't know what to do about profiling. Our profiling tools are crusty
enough, though, that I wonder if it's even worth arranging to profile
PIE executables, when we can't profile dynamically linked ones!
Thor
Home |
Main Index |
Thread Index |
Old Index