[Bug librt/33732] (gentoo-specific) glibc-2.43 fails to build, clang, i486 and x86-64, undefined reference to `__memcpy_chk'

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=33732

--- Comment #11 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Sam James from comment #10)
> (In reply to Andreas K. Huettel from comment #9)
> > (In reply to Adhemerval Zanella from comment #8)
> > > (In reply to Andreas K. Huettel from comment #7)
> > > > We add in the clang configuration a short include file to unconditionally 
> > > > enable fortification (though at level 2). 
> > > 
> > > Indeed, glibc build do not expect _FORTIFY_SOURCE to be enabled.  Maybe we
> > > should unconditionally undef it.
> > 
> > We do that already, I think. Most of the calls during glibc build contain
> > something like
> >   -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
> > to make sure everything is alright.
> > 
> > Also rtld.os is built with -U_FORTIFY_SOURCE (see comment 6) - which seems
> > to somehow get overridden by our include file...
> 
> The issue is, I think, that for our gcc enablement of F_S, we do it
> intelligently (as a C++ patch), while for clang, we do it all via header
> hacks, so it doesn't know the difference between "was never defined" and
> "just got undefined by -U", as I think "-U..." "runs first" before -include,
> while for the GCC approach, the "patch" default takes effect first, then -U
> on the cmdline wins.
> 
> A -D_GENTOO_NO_FORTIFY_SOURCE would work (libstdc++ has introduced
> _GLIBCXX_NO_ASSERTIONS for a similar kind of problem) but it's distro
> specific which is unfortunate.
> 
> We either need to change what we do in Gentoo (to what? we want to avoid
> patching if possible), or do inline #undef in source files, I think.

We now have a configure check to disable both _FILE_OFFSET_BITS (3f1932ed2e6)
and _TIME_BITS (4d8965f1304) if compiler defines it while building glibc (it
was a source of multiple bug report over the years). I think we can for
something similar for _FORTIFY_SOURCE, since it should be explicit enabled by a
configure switch and it is handled internally (since some modules should not be
built with it).

-- 
You are receiving this mail because:
You are on the CC list for the bug.