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

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

--- Comment #10 from Sam James <sam at gentoo dot org> ---
(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.

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