From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: hjl@lucon.org Cc: gas2@cygnus.com, libc-hacker@gnu.org Subject: Re: An ELF linker patch Date: Thu, 30 Apr 1998 12:07:00 -0000 Message-id: <199804301907.PAA22162@subrogation.cygnus.com> References: X-SW-Source: 1998/msg00170.html From: hjl@lucon.org (H.J. Lu) Date: Thu, 30 Apr 1998 11:53:55 -0700 (PDT) This patch fixes the bug with # gcc -O -g -o sharedstatic main.c libfoo.so -Wl,-rpath,. -Wl,-Bstatic under glibc 2.1. The problem is there are some data symbols defined in both the dynamic linker as well as libc.a under glibc 2.1. When -Wl,-Bstatic is added at the end, the dynamic linker and libc.a are used for the final link. As the result, those data symbols are defined in the dynamic executable. But when it runs, the dynamic linker will be invoked by the kernel to load the dynamic executable. During the loading, the data symbol definitions in the dynamic linker are used. But after switching to the executable, the definitions in the executable are used. It doesn't work very well since the dynamic linker depends on those data symbols very much. This patch seems to fix the problem by loading the dynamic linker first before anything else such that the definitions in libc.a are not used if the dynamic linker presents. It's not correct in general to link against the dynamic linker, so I don't think this patch is correct. Moreover, even if it were correct, it would only work when using the --dynamic-linker option, so it is fragile. Moreover, it is clearly wrong when cross linking. If you are trying to solve a problem specific to the glibc build process, why not change the above line to explicitly link against the dynamic linker? If you are trying to solve a more general problem, then it seems that there must be magic symbols in the dynamic linker. Your bug report lacks specific information, but I don't see how this could arise in any other way. If there are magic symbols in the dynamic linker, then I would suggest that the dynamic linker handle them magically. Perhaps if you provide some more specific information, like what the actual bug is, I can suggest a different way to address the problem. Ian