Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking

Jakub Jelinek jakub at redhat.com
Fri Sep 4 15:04:53 UTC 2015


On Fri, Sep 04, 2015 at 05:00:15PM +0200, Florian Weimer wrote:
> On 09/04/2015 04:11 PM, Jakub Jelinek wrote:
> > On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote:
> >> On 09/04/2015 03:49 PM, Jakub Jelinek wrote:
> >>
> >>> Clearly it is used by some programs, so it should be considered part of the
> >>> public API.  If it wasn't meant to be exported, it should not have been
> >>> exported.  The ld.so warning is only emitted if there is a copy relocation
> >>> against that symbol and the symbol has different size in the copy relocation
> >>> vs. the new size in the shared library.
> >>
> >> Ugh, I forgot.
> >>
> >> Will the process use the size from the shared library, or will the
> >> object be truncated, so that when the library tries to traverse the
> >> array (using its hard-coded size), it will read past the end of the
> >> allocated portion?
> > 
> > It copies the minimum of the two sizes.
> 
> Do references in other dynamic shared objects matter for determining the
> final size?  Or is this simply between the main program and the library
> which defines the symbol?

Well, only the program (normal or PIE) and the DSO that defines the symbol
matters for determining the size that is copied by the copy relocation
of course.  But, other DSOs (which do not use copy relocations) will
supposedly refer to the definition in the main program, so in this case
one with the smaller size (if any).

	Jakub


More information about the devel mailing list