On 8/13/19 1:38 PM, Kamil Dudka wrote:
On Tuesday, August 13, 2019 12:22:17 PM CEST Panu Matilainen wrote:
On 8/13/19 1:19 PM, Kamil Dudka wrote:
On Tuesday, August 13, 2019 11:26:12 AM CEST Panu Matilainen wrote:
On 8/13/19 11:17 AM, Igor Gnatenko wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1738293
How did it pass review?
Obsoletes: compton
Silently doing Obsoletes of an active package and doing so even
without version which is prohibited by the Packaging Guidelines.
Really?
cp -a yshui-%{appname}-%{test_shortcommit}/subprojects/test.h
/builddir/build/BUILD/%{appname}-%{version}/subprojects/
I am not sure if it is written anywhere, but hardcoding
/builddir/whatsoever is so bad…
%meson --buildtype=release
There is specific reason why we have --buildtype=plain in %meson
macro, because with release buildtype, debuginfo is unusable…
# Enable LTO
%global optflags %{optflags} -flto=$(nproc)
%global build_ldflags %{build_ldflags} -flto
Have anybody ever talked to the RPM folks about proper way of enabling
LTO for builds? This specific way of setting it makes build
non-reproducible.
Rpm can't help it if gcc/linker argument makes builds non-reproducable.
That said, see https://github.com/rpm-software-management/rpm/pull/809,
gcc upstream is aware of the issue and supports -flto=auto now, which is
what builds should be using for reproducability.
- Panu -
By reproducibility you mean that the number of jobs can be (in some
cases)
controlled by RPM macros?
Does the number of jobs have any impact on the resulting binary?
See the above URL.
It doesn't affect the actual link stage, but it affects the stored
optflags in the package (and the actual binaries if that was enabled)
- Panu -
OK, got it. The issue is that -flto=N can be stored in the resulting binary
RPMs and the N can differ across builds. So you want to use -flto=auto to
always store the same flag, even though the flag may have different semantics
in different builds of the same package.
Sorry for not understanding it originally. It is good idea to provide some
context when you post to such generic list as fedora-devel. Not all readers
are experts in all topics and/or have capacity to read in depth all referred
documents.
Not all, of course. I did assume that people actually interested in the
subject would go and read it ;)
The plot thickens though (again, its all in the referred PR), and now
that the cat is out of the bag I really do need to clarify it further here:
Contrary to what was said above, gcc does not, and apparently will not,
have an -flto=auto option. It was proposed for gcc 10, but instead the
basic form -flto will default to that behavior. Seems sane to me.
Or that's how it currently stands, AFAICS. We're still talking about
unreleased software so you never really know until it ships.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
