[K42-discussion] Annoyances with glibc_subset.symbols

[Bryan S Rosenburg]

I don't think I understand the issue.  The shared library is always loaded 
at a well-known address in all address spaces, and I thought it was linked 
specifically at that address.  Doesn't the link step relocate any non-PIC 
code?  I have to be missing something.

We used to have our own copies of lots of utility routines such as 
memmove(), but ours weren't optimized nearly as well as those in glibc. 
I'm surprised that any of our versions have survived.  I think it would be 
too bad if we have to go back to maintaining our own implementations, but 
if the glibc versions really can't be used, I guess we'll have to.

- Bryan




"Patrick G. Bridges" <bridges at cs.unm.edu> 
Sent by: k42-discussion-bounces+rosnbrg=us.ibm.com at ozlabs.org
10/09/2007 12:43 AM
Please respond to
Discussion about K42 <k42-discussion at ozlabs.org>


To
k42discuss <k42-discussion at ozlabs.org>
cc

Subject
[K42-discussion] Annoyances with glibc_subset.symbols






So, in trying to link parts of the k42 shared library, I've run into 
an annoyance - some of the objects extracted from glibc (specifically 
wordcopy.o) aren't position-independent on the x86_64 and so can't be 
used in the shared library.

So, a questions - there's an implementation of memmove in k42's lib/ 
libc. Is there any particular reason *that* version isn't used in the 
k42 shared library?

-Patrick
_______________________________________________
K42-discussion mailing list
K42-discussion at ozlabs.org
https://ozlabs.org/mailman/listinfo/k42-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20071009/772f467d/attachment.htm