Re: Multiple definition of __memcpy_chk

[Bryan Ischo <bryan at ischo dot com>]

On 08/19/11 06:58, Mike Frysinger wrote:
> On Friday, August 19, 2011 01:11:17 Bryan Ischo wrote:
> > On 08/18/11 21:27, Mike Frysinger wrote:
> > > On Thursday, August 18, 2011 23:57:30 Bryan Ischo wrote:
> > > > On 08/18/11 20:45, Mike Frysinger wrote:
> > > > > On Thursday, August 18, 2011 18:15:23 Bryan Ischo wrote:
> > > > > > Then when I go to compile gcc, it tries to compile and link libssp,
> > > > > > and that also defines its own __memcpy_chk.
> > > > > your gcc is misconfigured.  dont enable libssp for glibc builds.
> > > > Care to explain?  Why is it misconfigured?  Why can't libssp be compiled
> > > > against a static libc?  Is there a reason beyond "both glibc and gcc
> > > > have chosen the same name for a symbol"?
> > > libssp makes no sense with glibc.  its symbols are provided by glibc
> > > already.
> > Thank you for your response.  So are you saying that any system that is
> > expected to use glibc as its C runtime library should not enable libssp
> > when compiling gcc?  In what situation would someone enable libssp in gcc?
> glibc isnt the only C library out there
> -mike

I think I was confused between the linking of gcc itself and the linking 
of programs generated by that gcc.  I had assumed that gcc used its ssp 
as another library that it automatically links into programs, like it 
does for libgcc, and given that I didn't understand how gcc could do 
that if it was linking programs that linked against glibc with the 
duplicate symbols.  Your terse and almost completely uninformative 
answer did at least lead me to the line of thinking which in which I 
believe I came to the correct conclusion, which is: disable ssp if 
you're linking gcc against glibc, otherwise enable it.

Bryan