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

[christos%zoulas.com@localhost (Christos Zoulas)]

On Oct 17,  2:13pm, tls%rek.tjls.com@localhost (Thor Lancelot Simon) wrote:
-- Subject: Re: /usr/obj/gnu/lib/libiberty/libiberty.a: could not read symbol

| 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).

I think all of this can be handled with gcc spec magic.

| > 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...

Yes, I agree.

| 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!

Well we could have:

libfoo.a        non pic
libfoo_pic.a    pic
libfoo_p.a      non pic profiling
libfoo_pic_p.a  pic profiling
libfoo_g.a      non pic debugging
libfoo_pic_g.a  pic debuging

MKPIE building always enable
libfoo_pic.a    pic
libfoo_pic_p.a  pic profiling
libfoo_pic_g.a  pic debuging

to allow for PIE executables to build. On platforms where PIC is the default
(vax, mips, others?) the _pic.a versions could be hard-links to the non-pic
versions.

christos