[systemd-devel] [PATCH] build: Honour SUID_CFLAGS and SUID_LDFLAGS

Reindl Harald h.reindl at thelounge.net
Wed Jul 2 04:57:28 PDT 2014


the main question is *why* is it systemd's business?

that flags are generelly set at the distribution level
and in case of Fedora they can differ between archs
because each arch has it's own %{optflags}

the whole mess exists because upstream projects
don't leave their fingers from that flags at all

Am 02.07.2014 13:52, schrieb Umut Tezduyar Lindskog:
> I am agreeing with Simon. We use mips and we see the mentioned
> impacts. We also see quite size difference (%6 large on systemd-cat
> binary text section) which might not be so welcomed on embedded
> system.
> 
> Umut
> 
> On Mon, May 19, 2014 at 12:37 PM, Simon McVittie
> <simon.mcvittie at collabora.co.uk> wrote:
>> On 18/05/14 16:47, Cristian Rodríguez wrote:
>>> OK, Let's try [building everything -fPIE] instead.
>>
>> Hopefully things have improved since 2011, but my experience with
>> dbus[1] has been that this works fine on mainstream architectures, but
>> frequently fails on embedded architectures (arm* family, mips* family,
>> etc.) where various toolchain versions have been known to fail to
>> compile, fail to link, or worse, link binaries that sometimes or always
>> crash at runtime (which is hard to detect in a configure script without
>> breaking cross-compilation).
>>
>> libtool has relatively intelligent handling of the PIE compiler flags,
>> so if a distro wants to enable -fPIE (or other hardening options like
>> -Wl,-z,relro) it's easy for that distro to enable PIE by passing
>> appropriate CPPFLAGS, CFLAGS, LDFLAGS, etc. to the configure script,
>> which works for any libtool + Autoconf + Automake project without
>> modification:
>>
>>     ./configure CFLAGS=-fPIE LDFLAGS=-pie
>>
>> In distributions where not all architectures have the same level of
>> upstream toolchain support, centralizing the decision about compiler
>> flags to one place (e.g. dpkg-buildflags, and previously
>> hardening-wrapper, in Debian) means it's possible to avoid broken flag
>> combinations per-architecture, without having to encode that knowledge
>> into each package.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140702/c1439607/attachment-0001.sig>


More information about the systemd-devel mailing list