search for: canbenullatruntime

...not sure what to call it. > > This is needed for TLS. A undefined symbol could be set to TLS, so that symbols are resolved with the same type. Yes. >> Also the mach-o linker will need to know if a SharedLibraryAtom is a weak-definition or not. > The SharedLibraryAtoms have a field canBeNullAtRuntime, could this be used for weak definitions ? I think you are confusing the two overloaded uses of "weak". canBeNullAtRuntime is for "weak imports" (can be missing at runtime). "Weak definitions" are used with C++ (can be multiple at runtime). For instance operator new...

...for undefinedAtoms too, not sure what to call it. This is needed for TLS. A undefined symbol could be set to TLS, so that symbols are resolved with the same type. > Also the mach-o linker will need to know if a SharedLibraryAtom is a weak-definition or not. The SharedLibraryAtoms have a field canBeNullAtRuntime, could this be used for weak definitions ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

On Sep 23, 2013, at 4:52 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. > > #include <stdio.h> > > int main() { > fputs("hi\n", stdout); > } > > The reason is that stdout gets a R_X86_64_PC32 relocation, but is

The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. #include <stdio.h> int main() { fputs("hi\n", stdout); } The reason is that stdout gets a R_X86_64_PC32 relocation, but is of type Object. The ELF writer can't see this, and assumes all R_X86_64_PC32 relocations in dynamic outputs are to functions