[K42-discussion] Annoyances with glibc_subset.symbols

[Patrick G. Bridges]

On Oct 9, 2007, at 7:15 AM, Bryan S Rosenburg wrote:

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

The problem is that the gcc toolchain won't generate a shared library  
that contains one of the relocations in the extracted wordcopy.o:

gcc -nostdlib -nostartfiles -shared -fPIC               \
             -o ../x86_64/fullDeb/lib/libk42sys.so. 
1.tmp                 \
             ../x86_64/fullDeb/lib/k42sys.o ../x86_64/fullDeb/lib/ 
plt.o  \
             -Wl,-e,_k42start                                    \
             -Wl,-Bsymbolic                                      \
             -Wl,-z,combreloc                                    \
             -Wl,--version-script=../x86_64/fullDeb/lib/k42sys.map \
             -Wl,-T,../x86_64/fullDeb/lib/k42sys.scp \
             -Wl,-Map,../x86_64/fullDeb/lib/k42sys.loadmap \
             -Wl,-soname=libk42sys.so.1
/usr/bin/ld: ../x86_64/fullDeb/lib/k42sys.o: relocation R_X86_64_32S  
against `a local symbol' can not be used when making a shared object;  
recompile with -fPIC
../x86_64/fullDeb/lib/k42sys.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

It turns out, after some objdump hunting, that this relocation comes  
from wordcopy.o extracted from glibc. I could change how we generate  
this shared object to get around this by not actually making it a  
shared object, I guess, but I'm trying to keep things relatively  
similar to how they're already done...

-Patrick