This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> If we do not, then we will fail to implement the model correctly. > Consider the case in which a main executable defines a symbol weakly, > and a shared library does not define it at all. At present we will > not generate any dynamic relocations for the weak defined symbol. > > However, if we later replace the shared library with one which does > have a strong definition for the symbol, then correct operation would > appear to require that that strong symbol override the weak symbol in > the main executable. > > As far as I can see, this can only happen if all relocations involving > the weak defined symbol are copied into the executable as dynamic > relocations. What if the definition in executable is strong? Do you have the same problem? I don't think we should worry about this. > > Are we willing to pay that price for all weak defined symbols in all > dynamically linked executables? > > Should we instead go for the half-measure of only copying relocations > for weak defined symbols in the case where we link against a shared > library which has a strong definition for the symbol? It's easy to > predict that we will get bug reports on this in the future. > I have sent a patch to implement this. H.J.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |