Hi!

On Thu, 2016-11-24 at 14:52:33 +0000, Thorsten Glaser wrote:

clone 845193 -1
reassign -1 dpkg
retitle -1 dpkg: please do not add -specs= flags only on some architectures thanks

I'm afraid I'll have to wontfix this because it is not really
implementable. See below… :/

Guillem Jover dixit:

Those specs files should make it possible to build stuff with PIE

Yes, but they *do* break anything that
- acts on the CFLAGS (and LDFLAGS) variables
- uses klcc or other compiler wrappers that don't understand -specs
- uses clang or pcc or whatever other compilers

The default dpkg build flags have always been tied to the specific
language compiler version currently marked as the default (for C that
would currently be gcc-6).

Worse, they break *differently* on whether…

Precisely to make the behavior consistent on all architectures, dpkg >enables PIE (conditionally if no other flags marks it as to be
disabled) on all architectures were gcc has not enabled this by
default.

… that. And that is just plain wrong. Either dpkg should inject
-specs= stuff on all architectures or on none. Differing like this
just invites hidden and hard to track down bugs.

As long as gcc enables PIE on a subset, there will be need to inject
some form of specs on either subset of those arches, either on
hardening=+pie or on hardening=-pie, pick yout poison. :(

Injecting just the raw -fno-PIE and -no-pie does not work, so when you
need to disable those we need to pass via specs files.

Please get an agreement with the GCC maintainer on how to proceed
from here.

Personally, I’d still prefer for GCC to behave as on other systems,
i.e. not to enable PIE by default, and to have it done completely
within dpkg, but I can *also* live with it being done exclusively
in GCC.

Either are *much* better than the current way.

Well you and me both, I'm just adapting the dpkg-buildflags to the
current gcc situation. :/

Also BTW the gcc maintainer asked that porters
interested could request PIE to be enabled by default in gcc.

What difference does it make on whether GCC or dpkg enables PIE?

It means it should at least get the same behavior from gcc as all
official ports, it is more transparent and should not suffer from
unbalanced passing of CFLAGS w/o LDFLAGS or the other way around,
for example. Of course that does not mean that package might still
not fail, in case they try to link PIE code into a shared library
or similar.

The two last quote sections make it clear that any architecture
that currently has PIE enabled in dpkg should have it enabled in
GCC in the first place.

Enabling new build flags in dpkg has always been done globally,
except for specific blacklists on things that were completely broken
in the toolchain, which have then been enabled eventually when they
got fixed.

Having a subset of architectures is a pain for maintainers as they
get different resulting objects depending on the architectures, it
also changes the semantics from before the gcc default change, as
previously explicitly enabling PIE was global, and now would be for
a subset.

Or worse, the new semantics would need to be that by default you get
PIE on a subset but if you pass hardening=+pie on each package you get
it enabled globally? Pretty unintuitive IMO.

(Did dpkg enable that on porters’ requests?
It does not look like that to me. This smells like overstepping
boundaries.)

If porters are unhappy about this, I'll revert PIE for those ports in
dpkg, but this will not make the situation less of a mess, hardening=-pie
will still need the specs files on ports were gcc enables it by default,
and hardening=+pie might need them on the ones that do not…

tl;dr: I don’t care as much _which_ of GCC xor dpkg does it,
as long as only one does it. FFS, just enable it on all of them
unless known to absolutely not work; that’d still be better than
the current mess.

Well I think we should be enabling all hardening flags directly in
gcc, but now that we have the specs files I guess it would not be
too bad to enable them just in dpkg, but I agree either would be
preferable. :/

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)