Re: super-drafty F28 and F29 schedules

[Jeff Law]

On 07/13/2017 09:27 AM, Matthew Miller wrote:
> On Thu, Jul 13, 2017 at 09:23:58AM -0600, Jeff Law wrote:
>>>> Likewise.  We should keep this schedule in mind as we work our way
>>>> through stage3 into stage4.  Ideally Marek would start the test builds
>>>> prior to the Christmas break, even if we're still in stage3.
>>>> We'll review on the 9th and 16th with go/no-go decisions on the 23rd and
>>>> 30th.
>>> Which months are these? :)
>> January 2018 as we approach the mass rebuild.  We'll want to review the
>> state of the test builds as well as other incoming bugs for things that
>> are most important leading into the official mass rebuild of F28.
> 
> You mentioned possibly shifting the GCC process a little bit earlier.
> Is it possible to maybe do that as well here, to give a little more
> breathing room? Maybe even not for 2018 but for beyond, as we intend to
> keep to this schedule for the foreseeable future.
That's my hope -- I'll be pushing internally and externally to shift
things by a couple weeks.  Whether or not the release managers and the
project as a whole will support that remains to be seen :-)

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: super-drafty F28 and F29 schedules

[Jeff Law]

On 07/13/2017 09:01 AM, Matthew Miller wrote:
> On Wed, Jul 12, 2017 at 03:14:24PM -0600, Jeff Law wrote:
>>> LGTM.
>> Likewise.  We should keep this schedule in mind as we work our way
>> through stage3 into stage4.  Ideally Marek would start the test builds
>> prior to the Christmas break, even if we're still in stage3.
>>
>> We'll review on the 9th and 16th with go/no-go decisions on the 23rd and
>> 30th.
> 
> Which months are these? :)
January 2018 as we approach the mass rebuild.  We'll want to review the
state of the test builds as well as other incoming bugs for things that
are most important leading into the official mass rebuild of F28.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: super-drafty F28 and F29 schedules

[Jeff Law]

On 07/12/2017 06:10 AM, Jakub Jelinek wrote:
> On Tue, Jul 11, 2017 at 09:36:28PM -0400, Carlos O'Donell wrote:
>> On 07/06/2017 09:15 PM, Matthew Miller wrote:
>>> https://fedoraproject.org/wiki/Releases/28/Schedule
>>
>> I encourage Jeff Law and Jakub Jelinek to review these schedules
>> for compiler related issues.
>>
>> This is just a perfunctory review from the glibc perspective with
>> regard to base ABI and API issues in this core runtime.
>>
>> 2018-01-10 MASS REBUILD
>> - This date is ahead of the glibc release on 2018-02-01
>>   but after the 2018-01-01 ABI freeze date for glibc.
>>   Therefore you will be largely assured a stable ABI upon
>>   which to base Fedora, _but_ there is a vanishingly small
>>   chance you may need a mass rebuild or a targeted rebuild
>>   on 2018-02-01 if something has to be reverted.
> 
> 2018-01-10 is way too early for a mass rebuild from GCC point of view,
> even if we perform the test mass rebuild over the Christmas break,
> there won't be enough time to analyze it and fix any GCC issues revealed
> during that time.
Right.  Optimistically, we'd let the test mass rebuild run over the
break giving the GCC team a nice pile of issues to look at in the start
of the new year.  But even in that scenario I can't in good conscience
recommend Fedora start mass rebuilds on 01-10 -- it's just not enough
time to triage the issues from the mass rebuild and get them fixed.

01-25 is probably the earliest I'd recommend scheduling a mass rebuild
from GCC's point of view.  Even that may be overly optimistic.


  GCC bugfixing usually starts around November 15th and
> needs some time before it can be fixed enough to use widely.
> Moving the mass rebuild one week earlier than last time
> is maybe doable, but not one month.  And not rebuilding F27 with GCC 8
> is a bad idea for both the compiler and Fedora.
FWIW I would like to see everything in the GCC process shift earlier by
a couple weeks.  I haven't had much success convincing folks to make
that shift though.



> 
> As for F29, there is no GCC release around that time, so from GCC POV the
> schedule doesn't matter that much.
Right.  The odd Fedora releases tend to just pick up whatever the latest
point release of GCC is available.   They don't tend to cause much work
or stress from a toolchain standpoint.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: super-drafty F28 and F29 schedules

[Jeff Law]

On 07/12/2017 02:54 PM, Jakub Jelinek wrote:
> On Wed, Jul 12, 2017 at 04:45:56PM -0400, Matthew Miller wrote:
>> On Wed, Jul 12, 2017 at 04:30:12PM -0400, Matthew Miller wrote:
>>> So, "one week earlier than last time" would be January 31st. (Or 30th?
>>> Depends if we want that on a Tuesday like everything else or Wednesday
>>> like this time around, if it matters.) Is that enough to help? Let me
>>> rework it and let's see what that looks like...
>>
>> So, what does updated
>> https://fedoraproject.org/wiki/Releases/28/Schedule#Key_Milestones look
>> like to you? That puts the mass rebuild on January 31st.
> 
> LGTM.
Likewise.  We should keep this schedule in mind as we work our way
through stage3 into stage4.  Ideally Marek would start the test builds
prior to the Christmas break, even if we're still in stage3.

We'll review on the 9th and 16th with go/no-go decisions on the 23rd and
30th.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 389-ds-base and freeipa on 32 bit arches

[Jeff Law]

On 02/23/2018 10:29 AM, Alexander Bokovoy wrote:
> On pe, 23 helmi 2018, Jeff Law wrote:
>> On 02/23/2018 09:58 AM, Randy Barlow wrote:
>>> Greetings gcc maintainers!
>>>
>>> A FESCo issue[0] has been filed due to the dropping of 389-ds-base and
>>> freeipa on 32 bit arches for Fedora 28. This was done without a change
>>> request being filed, so FESCo is trying to decide how best to handle it.
>>>
>>> It seems there are some concerns about whether the C tooling correctly
>>> handles some cases for 32-bit arches that led to the decision by the IPA
>>> maintainers to drop support for 32-bit. FESCo would like to ask for the
>>> GCC maintainers' input on the issue.
>>>
>>> Thanks in advance for your feedback!
>> GCC, binutils, etc all support 32-bit arches just fine.  THe current
>> thinking is there are serious concurrency concerns in the freeipa code
>> which are leading to the failures they were seeing on 32 bit platforms
>> (i686 in particular).
> To be clear there are concerns in 389-ds code that lead to data
> corruptions on i686. They aren't seen on other 32-bit platforms Fedora
> supports according to 389-ds developers.
Sorry to mis-characterize the problem.  It's the 389-ds code with the
concurrency concerns, not freeipa.

The fact that the 389-ds code works on other architectures does not
allow us to draw any conclusions at this point.  It really needs to go
through a root cause analysis to determine exactly why it is not working
correctly.  That will in turn tell us if it's the 389-ds code or
something in the compiler (or elsewhere) that is the problem.


Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 389-ds-base and freeipa on 32 bit arches

[Jeff Law]

On 02/23/2018 09:58 AM, Randy Barlow wrote:
> Greetings gcc maintainers!
> 
> A FESCo issue[0] has been filed due to the dropping of 389-ds-base and
> freeipa on 32 bit arches for Fedora 28. This was done without a change
> request being filed, so FESCo is trying to decide how best to handle it.
> 
> It seems there are some concerns about whether the C tooling correctly
> handles some cases for 32-bit arches that led to the decision by the IPA
> maintainers to drop support for 32-bit. FESCo would like to ask for the
> GCC maintainers' input on the issue.
> 
> Thanks in advance for your feedback!
GCC, binutils, etc all support 32-bit arches just fine.  THe current
thinking is there are serious concurrency concerns in the freeipa code
which are leading to the failures they were seeing on 32 bit platforms
(i686 in particular).

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gcc 10 plans for Fedora 32?

[Jeff Law]

On Wed, 2019-12-11 at 14:53 +0100, Miro Hrončok wrote:
> Hello,
> 
> what are the gcc 10 plans for Fedora 32? Will there be a change
> proposal for 
> that? Is Fedora 32 the target for gcc 10?
Plan is for gcc-10 to be the compiler for F32.  We coordinate with the
Fedora leaders on this each year as part of green-lighting the spring
mass rebuild (which doesn't start until after the gcc update).

Typically rawhide gets the GCC update in late Jan/early Feb.

> 
> I remember that gcc was updated to 9 during Fedora 30 cycle without a
> change 
> proposal and the change proposal was submitted later, after the
> deadline and 
> after gcc was already updated.
> 
> I'd like to avoid repeating this situation.
Updating gcc yearly for the spring Fedora release is standard
procedure.  However, we should still be filing the change proposals.


> If you already have a place to test our packages with gcc 10 (such as
> a copr 
> with gcc snapshot), please do tell, I'd like to see what Python
> versions are 
> impacted.
I have very rough packages I use in my tester.  I'm happy to point you
to them, but be aware they (for example) claim to be gcc-9 at the RPM
level.

file.rdu.redhat.com:~law/public_html/repo.Snapshot has the latest bits.
I typically update it Sunday nights to the latest gcc snapshot.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: devel Digest, Vol 190, Issue 187

[Jeff Law]

On Thu, 2019-12-19 at 22:14 +, devel-
requ...@lists.fedoraproject.org wrote:
Igor,

> Send devel mailing list submissions to
> 
> It would be very nice to get more specific analysis data. Like running
> some benchmarks of big applications, size comparisons (of binaries and
> libraries) and compile time.
Jan (from SuSE) probably has the best data on this.  
http://www.ucw.cz/~hubicka/slides/opensuse2018-e.pdf
https://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html

I don't have his 2019 Cauldron slides which discuss the most recent
improvements.  I'll put those links into the change proposal.


> 
> > This change also brings us back on-par with SuSE who enabled LTO by
> > default for their free distribution earlier in 2019.
> 
> You probably should have said openSUSE rather here.
Yea, openSUSE is more appropriate here.  I'll update that.

> 
> > == Scope ==
> > * Proposal owners:
> > The primary change is to redhat-rpm-config to add LTO to the default
> > compile/link flags as well as a conditional which allows easy opt-out
> > on a package by package basis.  Additionally the post-build scripts
> > need to strip the LTO bytecodes from any installed .o/.a files.
> 
> What does that mean? Which post-build scripts are needed and where
> that needs to be done? How does it affect build time?
There's one post-build script which strips the LTO bytecode. 
Essentially it's just like stripping debug info or the static symbol
table (like we already do), except we have to apply it to all the .o/.a
files.  The openSUSE guys already have these bits, odds are we'll just
copy 'em.

I wouldn't expect the stripping to be noticeable on the build time. 
LTO itself will certainly make things slower at build time.

> 
> > Additionally, we know there are many packages with configure scripts
> > that are compromised by LTO.  I have tweaks to the %configure macro in
> > redhat-rpm-config which fixes the vast majority of these problems with
> > a few simple sed scripts on the generated output.  Like the basic
> > support for injecting the LTO flags, this will require coordination
> > with the redhat-rpm-config maintainers.  Packages which call configure
> > directly and have compromised tests will need a one line change to
> > their .spec files to fix their configure scripts.
> 
> "simple sed scripts" are probably not so simple :)
There's 5 sed scripts I'm using within %configure.  Trust me, that's
dramatically easier than trying to fix every package with broken
configure scripts -- particularly when some of those configure files
were built with versions of autoconf that are 12+ years old.  Only two
of the 5 sed scripts are, IMHO as a non-sed person, complex.  This
avoids the need to fix several hundred packages.

There's certainly some straggler packages that have configure bits that
are unique to those packages rather than shared across many packages. 
Those I expect we'll just fix on a per-package basis (it's measured in
a dozen or two in the end I suspect).

I have a tester which allows me to build all the Fedora binary
packages.  So I build once with gcc-10+LTO, capture the generated
config.h files, then build again with the standard gcc-9 compiler. 
Then the resultant config.h files are compared.  If there's any
differences, the build is failed.


> 
> > Some packages will need to opt-out of using LTO at this time.  The
> > most common case are packages that use symbol versioning or toplevel
> > ASM statements.  While there is a new mechanism to make LTO work with
> > symbol versioning, I don't think any packages have been updated to use
> > that mechanism.  This will require a one line change to 50-75 packages
> > (my script to find these is still running).
> 
> Hmm, I think we have bunch of packages (more than 75 of them) which
> use symbol versioning. Would be useful to give some links in the
> change proposal to "how to update to use that mechanism".
Yup.  I've already got a (growing) list of 'em.  I've got ~50 on my
list and ~125 failures still to evaluate.

Ideally the opt-out mechanism for a package's .spec file would look
like:

%undefine _lto

Simple enough? :-)

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: devel Digest, Vol 190, Issue 186

[Jeff Law]

On Thu, 2019-12-19 at 21:56 +, devel-
requ...@lists.fedoraproject.org wrote:
> 

Neal,


> 
> I'm generally happy with this idea. I'm one of the maintainers of
> rpm-config-SUSE (the equivalent of redhat-rpm-config for SUSE
> distributions) and I somewhat saw the development of this feature
> across rpm, rpm-config-SUSE, and the implementation in openSUSE
> Tumbleweed.
Understood.  FWIW, I work closely with Martin L, Martin J, Jan and
Richi @ SuSE.  Martin L and I in particular coordinate on mass build
testing & related failure analysis and bugfixing.

> 
> However, the implementation of LTO in openSUSE caused major problems
> for "weaker" architectures like ARM and RISC-V. In Fedora, ARM is
> co-primary with the rest of the architectures (ARM is allowed to be
> broken in openSUSE from time to time). The major problems we
> encountered was increased miscompilation errors and timeouts due to
> builds taking even longer with LTO straining ARM build environments.
Yes.  The 32bit architectures in particular are expected to be slightly
problematical due to the limited address space.  Even with Jan's work
in this area, I expect things like firefox to simply be too big to
compile/link using LTO on the 32bit platforms.

When I discussed this with Martin L and one of the Ubuntu engineers
(Matthias) back in Sept, the general plan we agreed on was to first get
the Fedora test builds in reasonable shape on x86_64 that we could use
as a baseline (and we're just about there).  Then do an i686 build for
comparison purposes.

For packages we find problematical on the 32bit platforms, we'll be
able to trivially opt-out of LTO for that package on those 32bit
platforms.  It's a one-liner in the .spec file.


> 
> And with RISC-V, is LTO even implemented well in GCC? In OpenMandriva
> (where I help maintain rpm-openmandriva-setup, its equivalent of
> redhat-rpm-config), we're still using GCC for RISC-V since Clang is
> still horribly broken there, and we had to disable LTO to get a usable
> port going. Fedora RISC-V is going to be in for a world of pain if
> we're enabling it without any consideration for them.
GCC's implementation of LTO is target independent.

RISC-V really isn't on my radar at this point.  Though if we have
issues specific to the code generator on RISC-V, I'm sure Jim Wilson
(SiFive) and I can work it out.  We've been working together on GCC for
nearly 30 years at this point.  I would _not_ expect RISC-V's code
generator to be as solid as other platforms simply because it hasn't
been used much yet.

> 
> So what's the state of things for non-x86? Generally speaking, my
> experience indicates everything is broken...
My tester is x86_64 based.  There's no inherent reason it couldn't work
on another platform other than needing lots of machines to turn around
builds quickly enough to matter.  My hope has always been to spin up
i686 and ppc64le as I can get access to reasonable hardware for those
targets.

I've spoken with ARM's & IBM's GCC engineers about this upcoming
change, they're aware and supportive of the plan.  We typically lean
heavily on them to take care of any GCC issues that are specific to
their targets.

jeff  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: devel Digest, Vol 190, Issue 186

[Jeff Law]

On Thu, 2019-12-19 at 16:24 -0600, Neal Gompa wrote:
> On Thu, Dec 19, 2019 at 4:14 PM Jeff Law  wrote:
> > On Thu, 2019-12-19 at 21:56 +, devel-
> > requ...@lists.fedoraproject.org wrote:
> > 
> > Neal,
> > 
> > 
> > > I'm generally happy with this idea. I'm one of the maintainers of
> > > rpm-config-SUSE (the equivalent of redhat-rpm-config for SUSE
> > > distributions) and I somewhat saw the development of this feature
> > > across rpm, rpm-config-SUSE, and the implementation in openSUSE
> > > Tumbleweed.
> > Understood.  FWIW, I work closely with Martin L, Martin J, Jan and
> > Richi @ SuSE.  Martin L and I in particular coordinate on mass build
> > testing & related failure analysis and bugfixing.
> > 
> 
> Martin Liška is the one I've primarily interfaced with throughout the
> implementation.
> 
> I don't know if you know about this, but there's a tracker bug for
> LTO-related failures: https://bugzilla.opensuse.org/1133084
I am aware of it and have referenced it several times in my own work.

> 
> We should probably make sure this is cross-referenced as LTO is
> implemented in Fedora.
Sure.  That's easy enough to do.  Some of the information is dated, but
there still useful nuggets in there.

They punted lots of stuff though.  In particular they punted the
configure problem and middle-end issued diagnostics, which was terribly
unfortunate.

> 
> > > However, the implementation of LTO in openSUSE caused major problems
> > > for "weaker" architectures like ARM and RISC-V. In Fedora, ARM is
> > > co-primary with the rest of the architectures (ARM is allowed to be
> > > broken in openSUSE from time to time). The major problems we
> > > encountered was increased miscompilation errors and timeouts due to
> > > builds taking even longer with LTO straining ARM build environments.
> > Yes.  The 32bit architectures in particular are expected to be slightly
> > problematical due to the limited address space.  Even with Jan's work
> > in this area, I expect things like firefox to simply be too big to
> > compile/link using LTO on the 32bit platforms.
> > 
> > When I discussed this with Martin L and one of the Ubuntu engineers
> > (Matthias) back in Sept, the general plan we agreed on was to first get
> > the Fedora test builds in reasonable shape on x86_64 that we could use
> > as a baseline (and we're just about there).  Then do an i686 build for
> > comparison purposes.
> > 
> > For packages we find problematical on the 32bit platforms, we'll be
> > able to trivially opt-out of LTO for that package on those 32bit
> > platforms.  It's a one-liner in the .spec file.
> > 
> > 
> 
> Are we going to use the same %_lto_cflags mechanism that was
> implemented in openSUSE, or are we going to do something different?
Ideally the same.  I don't own redhat-rpm-config, but certainly my
preference is use the same mechanisms.

> 
> 
> I'd like to see at *least* AArch64 spun to see how well this goes. I'm
> reasonably confident that POWER8+ would be fine, since we don't have
> ppc64be anymore (and I *know* that one was broken, since I reported it
> years ago: https://bugzilla.redhat.com/1515934).
Obviously aarch64 will be built and any issues resolved as is the case
with other architectures.  We do this every spring cycle with the
introduction of a major GCC release and we work closely with the GCC
engineers at ARM and IBM along the way.

Building 9000 packages 3X each (gcc-10+LTO, gcc-10, gcc-9 baseline)
takes significant hardware.  If there's hardware I can use (and you
should be thinking on the order of dozens of dedicated machines), then
I'm happy to use them.  I mentioned ppc64le simply because I can get
access to a goodly number of them.


Thanks for that reference.  Big endian ppc.  Ugh.  But in the end it's
just code.  

Jeff



> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: devel Digest, Vol 190, Issue 186

[Jeff Law]

On Sat, 2019-12-21 at 10:52 -0500, Josh Boyer wrote:
> On Thu, Dec 19, 2019 at 5:48 PM Jeff Law  wrote:
> > On Thu, 2019-12-19 at 16:24 -0600, Neal Gompa wrote:
> > > On Thu, Dec 19, 2019 at 4:14 PM Jeff Law  wrote:
> > > > On Thu, 2019-12-19 at 21:56 +, devel-
> > > > requ...@lists.fedoraproject.org wrote:
> > > > 
> > > > Neal,
> > > > 
> > > > 
> > > > > I'm generally happy with this idea. I'm one of the maintainers of
> > > > > rpm-config-SUSE (the equivalent of redhat-rpm-config for SUSE
> > > > > distributions) and I somewhat saw the development of this feature
> > > > > across rpm, rpm-config-SUSE, and the implementation in openSUSE
> > > > > Tumbleweed.
> > > > Understood.  FWIW, I work closely with Martin L, Martin J, Jan and
> > > > Richi @ SuSE.  Martin L and I in particular coordinate on mass build
> > > > testing & related failure analysis and bugfixing.
> > > > 
> > > 
> > > Martin Liška is the one I've primarily interfaced with throughout the
> > > implementation.
> > > 
> > > I don't know if you know about this, but there's a tracker bug for
> > > LTO-related failures: https://bugzilla.opensuse.org/1133084
> > I am aware of it and have referenced it several times in my own work.
> > 
> > > We should probably make sure this is cross-referenced as LTO is
> > > implemented in Fedora.
> > Sure.  That's easy enough to do.  Some of the information is dated, but
> > there still useful nuggets in there.
> > 
> > They punted lots of stuff though.  In particular they punted the
> > configure problem and middle-end issued diagnostics, which was terribly
> > unfortunate.
> > 
> > > > > However, the implementation of LTO in openSUSE caused major problems
> > > > > for "weaker" architectures like ARM and RISC-V. In Fedora, ARM is
> > > > > co-primary with the rest of the architectures (ARM is allowed to be
> > > > > broken in openSUSE from time to time). The major problems we
> > > > > encountered was increased miscompilation errors and timeouts due to
> > > > > builds taking even longer with LTO straining ARM build environments.
> > > > Yes.  The 32bit architectures in particular are expected to be slightly
> > > > problematical due to the limited address space.  Even with Jan's work
> > > > in this area, I expect things like firefox to simply be too big to
> > > > compile/link using LTO on the 32bit platforms.
> > > > 
> > > > When I discussed this with Martin L and one of the Ubuntu engineers
> > > > (Matthias) back in Sept, the general plan we agreed on was to first get
> > > > the Fedora test builds in reasonable shape on x86_64 that we could use
> > > > as a baseline (and we're just about there).  Then do an i686 build for
> > > > comparison purposes.
> > > > 
> > > > For packages we find problematical on the 32bit platforms, we'll be
> > > > able to trivially opt-out of LTO for that package on those 32bit
> > > > platforms.  It's a one-liner in the .spec file.
> > > > 
> > > > 
> > > 
> > > Are we going to use the same %_lto_cflags mechanism that was
> > > implemented in openSUSE, or are we going to do something different?
> > Ideally the same.  I don't own redhat-rpm-config, but certainly my
> > preference is use the same mechanisms.
> > 
> > > 
> > > I'd like to see at *least* AArch64 spun to see how well this goes. I'm
> > > reasonably confident that POWER8+ would be fine, since we don't have
> > > ppc64be anymore (and I *know* that one was broken, since I reported it
> > > years ago: https://bugzilla.redhat.com/1515934).
> > Obviously aarch64 will be built and any issues resolved as is the case
> > with other architectures.  We do this every spring cycle with the
> > introduction of a major GCC release and we work closely with the GCC
> > engineers at ARM and IBM along the way.
> > 
> > Building 9000 packages 3X each (gcc-10+LTO, gcc-10, gcc-9 baseline)
> > takes significant hardware.  If there's hardware I can use (and you
> > should be thinking on the order of dozens of dedicated machines), then
> > I'm happy to use them.  I mentioned ppc64le simply because I can get
> > access to a goodly number of them.
> 
> Is there a reason you couldn't use aarch64 AWS instances?
I've actually applied for aws credits which could be used for this. 
THe instances in the free tier are too small to really be useful.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: digested list etiquette [ was: devel Digest, Vol 190, Issue 186 ]

[Jeff Law]

On Fri, 2019-12-20 at 12:59 -0500, Robbie Harwood wrote:
> Hi,
> 
> When replying to digests, I'd appreciate if you could please make an
> effort to have the posts thread properly for the rest of us.  Fedora
> mailing list guidance on this:
> https://fedoraproject.org/wiki/Mailing_list_guidelines#Replying_to_Digests
Will do.  Sorry for making things harder on everyone in this regard.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: LTO by default for package builds

[Jeff Law]

On Fri, 2019-12-20 at 11:52 +0100, Miro Hrončok wrote:
> On 19. 12. 19 22:41, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/LTOByDefault
> > 
> > == Contingency Plan ==
> > * Contingency mechanism: Revert the LTO flags injection
> > * Contingency deadline: Beta freeze, but shooting for prior to mass
> > rebuilds starting
> > * Blocks release? No
> > * Blocks product? No
> > 
> > Most critically, if we don't address the GDB testsuite issue noted
> > above, our fallback position would be to simply disable the LTO
> > injection globally and re-evaluate for Fedora 33, similarly if we were
> > to find some show-stopping LTO issue.
> 
> Should the contingency plan include a second mass rebuild in case our 
> packages 
> successfully built with lto during the mass rebuild, but are broken at 
> runtime?
> 
> Or do we safely assume that it's good as long as it builds fine?
It would really depend on what we find and it's the kind of decision we
deal with semi-regularly with the yearly compiler update in Fedora --
what to do if we find something horrifically wrong, whether it be an
unexpected ABI change or a particularly nasty codegen issue.

When we encounter these situations we often end up instrumenting the
compiler to get a sense of how pervasive the problem is or building a
scanner to look for problematic code sequences across the builds done
with the problematic compiler/options.

To-date I don't think we've ever had to do something like back out a
major compiler update or request a mass rebuild in Fedora as a result
of a compiler issue.  We've had some "phew" moments for issues we
thought were going to have wide impact, but for various reasons didn't.

So while I wish I could give you a concrete answer, it's really
something we (Jakub, Marek, Jason, Jon, myself and others) evaluate on
a case by case basis looking at size/scope and determine a path
forward, knowing that an unexpected mass rebuild would be catastrophic.

What gives me a relatively high degree of confidence in the
introduction of LTO is that openSUSE made this change for their distro
in the spring of this year confirming the base LTO technology on a wide
scale, combined with the testing we're already doing for Fedora with
gcc-10.

By *far* the biggest issue with LTO is the configure test snippets that
are so horribly written that they can be easily compromised by
aggressive optimization enabled by LTO and the widespread nature of
that horrific code.  Hence the desire to fix the most common and
egregious issues by in-place editing of the already-generated configure
files within %configure.  And just to be clear, these code snippets
would never actually run and nobody would ever write code this way
expecting it to be executed -- they're primarily compile/link tests to
look for features.  Concerns over mis-configuring packages due to these
issues is what led to the introduction of the capability to capture the
generated config.h files and compare them against builds with standard
tools in our tester.  If we note any differences in the generated
config.h files, the build is considered a failure and needs to be
examined and the issue fixed.

jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Non-responsive maintainer check for libffi maintainer

[Jeff Law]

On Mon, 2020-02-24 at 13:02 +, devel-
requ...@lists.fedoraproject.org wrote:
> 
> Date: Mon, 24 Feb 2020 12:10:49 +0100
> From: Miro Hrončok 
> Subject: Re: Non-responsive maintainer check for libffi maintainer
> To: Anthony Green 
> Cc: Development discussions related to Fedora
>   
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> On 24. 02. 20 1:46, Anthony Green wrote:
> >I would be very happy if somebody could pick up the libffi packaging
> > responsibility from me.
> 
> Suggestion: Try announcing on devel list that you are seeking co-maintainers 
> (from a separate thread). If that doesn't help, orphan the package and see 
> who 
> cares enough to take it.
> 
> I've also CC'ed the RHEL Bugzilla default assignee, DJ Delorie.
> 
> There are plenty of components that need libffi including various Python 
> versions and Ruby.
At this point it probably makes sense to hand libffi off to DJ (who
took it over in RHEL fairly recently).  I can give DJ a heads-up.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 Mass Rebuild

[Jeff Law]

On Mon, 2020-01-27 at 21:23 +0100, Fabio Valentini wrote:
> On Mon, Jan 27, 2020 at 4:46 PM Jeff Law  wrote:
> > On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote:
> > > On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote:
> > > > Hi all,
> > > > 
> > > > Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
> > > > Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
> > > > changes:
> > > > 
> > > > https://fedoraproject.org/wiki/Changes/GLIBC231
> > > > https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33
> > > > https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
> > > > https://fedoraproject.org/wiki/Changes/golang1.14
> > > > https://fedoraproject.org/wiki/Changes/GCC10
> > > > https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0
> > > > 
> > > > we will start the mass rebuild on 2020-01-27
> > > 
> > > I thought the mass rebuild should be also for
> > > https://fedoraproject.org/wiki/LTOByDefault
> > > but the required changes AFAIK haven't landed into redhat-rpm-config yet.
> > > 
> > > CCing Jeff on the current state.
> 
> (snip)
> 
> > After finally starting looking at the LTO vs GDB issues last week, I
> > think we should defer LTO until F33.  There's just too many GDB
> > failures when used with LTO that aren't understood yet.
> 
> Since the mass rebuild starts today (or has already started), you're
> cutting it pretty close there ...
> 
> So you'll either need to postpone to F33 or request a second mass
> rebuild - soon.
> 
> Can you comment on the FESCo ticket with the current status? Just to
> keep us in the loop
Umm, Ben and I were already discussing the situation this morning.  I
believe the page and fesco ticket both have current state (deferring to
F33).

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: cjdns with gcc-10 in Fedora

[Jeff Law]

On Wed, 2020-01-22 at 16:11 -0700, Jeff Law wrote:
> On Wed, 2020-01-22 at 22:03 +, devel-
> requ...@lists.fedoraproject.org wrote:
> > Send devel mailing list submissions to
> > devel@lists.fedoraproject.org
> > 
> > To subscribe or unsubscribe via email, send a message with subject or
> > body 'help' to
> > devel-requ...@lists.fedoraproject.org
> > 
> > You can reach the person managing the list at
> > devel-ow...@lists.fedoraproject.org
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of devel digest..."
> > 
> > Today's Topics:
> > 
> >1. Re: gcc 10: Default to -fno-common, multiple definitions of ...
> >   (Stephen John Smoogen)
> >2. Re: gcc 10: Default to -fno-common, multiple definitions of ...
> >   (Christoph Junghans)
> >3. Re: gcc 10: Default to -fno-common, multiple definitions of ...
> >   (Fabio Valentini)
> >4. Re: gcc 10: Default to -fno-common, multiple definitions of ...
> >   (Michael Cronenworth)
> >5. Orphaning argyllcms (Richard Hughes)
> > 
> > 
> > --
> > 
> > Date: Wed, 22 Jan 2020 15:30:45 -0500
> > From: Stephen John Smoogen 
> > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
> > ...
> > To: Development discussions related to Fedora
> > 
> > Message-ID:
> > 
> > Content-Type: text/plain; charset="UTF-8"
> > 
> > On Wed, 22 Jan 2020 at 14:54, Christoph Junghans  wrote:
> > > On Wed, Jan 22, 2020 at 4:42 AM Miro Hrončok  wrote:
> > > > jtaylornetsniff-ng ocaml-lablgtk suricata
> > > > junghans   gasnet
> > > 
> > > Sorry, how do I install gcc10 on Rawhide?
> > > "dnf upgrade --advisory=FEDORA-2020-a165791b6f" doesn't seem to do it.
> > > 
> > > Christoph
> > > 
> > 
> > Going from a similar discussion in #fedora-devel. There has been no
> > current compose of rawhide so it can not be synced out of the mirror.
> > In order to upgrade/install gcc10 you will need to  enable the local
> > repo in mock or replicate it on your system.
> > 
> > 2020-01-21 18:33:05  fedora-32 is still at gcc-9.2.1, but I got 
> > an em
> > ail saying cjdns no longer builds with gcc-10.  How do I rebuild with 
> > gcc-10 to
> > get this fixed?  I assume the goal is to get most packages ready for gcc-10 
> > befo
> > re upgrading rawhide.
> > 2020-01-21 18:58:03  sdgathman: rawhide/f32 already has 
> > gcc-10... the
> > re just hasn't been a successfull rawhide compose syncing it out to 
> > mirrors. You
> >  can do scratch builds or you could enable the 'local' repo in mock to use 
> > the k
> > oji buildroot...
> Note that cjdns, according to my tester, is building fine with gcc-10
> with and without LTO enabled as Jan 18th.
> 
> I know there was a bug in GCC that Martin Sebor fixed on Jan 13th that
> caused gcc-10 to issue a false positive out of bounds array index
> warning that in turn caused cjdns to fail.
Actually, I spoke with Martin today.  THe patch wasn't committed as
Jakub raised some concerns.  So, yes, this issue is still a concern.

jeff

ps.  My tester has Martin's patch, which explains why it's working...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: gcc 10: Default to -fno-common, multiple definitions of

[Jeff Law]

On Thu, 2020-01-23 at 17:23 -0500, Steve Grubb wrote:
> On Tuesday, January 21, 2020 1:52:54 PM EST Jeff Law wrote:
> > > > > That was the idea.   Provide a trivial opt-out so that upstreams had
> > > > > time to fix properly.  I even volunteered to add the opt-out marker
> > > > > where appropriate to minimize the FTBFS issues.  I also volunteered
> > > > > to help with the packages that don't honor flags injection.
> > > > 
> > > > This sounds reasonable to me.
> > > > 
> > > > The PR is
> > > > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77
> > > > 
> > > > I have reopened it.
> > > > 
> > > > The mass rebuild will notify the maintainrs and they can use that macro
> > > > to short-workaround the problem. It' also easier to grep from the specs
> > > > than custom patches and whatnots
> > > 
> > > I need something like this for suricata. It has about 45 variables
> > > causing this. And it's not a simple "extern" addition because it looks
> > > like in many cases the variable was never placed in a C file. Simply
> > > adding extern keyword leads undefined reference errors. This will take a
> > > while to sort out with upstream.
> > 
> > You also have to be careful if you're building shared libraries -- I
> > was looking at a package (I forget which) which built multiple DSOs.
> > If you're not careful you can end up with some DSOs which wouldn't have
> > the definition -- worse yet, you're not going to get an undefined
> > symbol when you build those DSOs.
> 
> So, I have a weird one. I'm compiling audit and getting multiple definitions.
> 
> I have
> 
> /usr/bin/ld: ausearch-checkpt.o:/home/sgrubb/working/BUILD/audit-3.0/src/
> ausearch-common.h:53: multiple definition of `event_node_list'; ausearch.o:/
> home/sgrubb/working/BUILD/audit-3.0/src/ausearch-common.h:53: first defined 
> here
> 
> $ cat ausearch-checkpt.c | grep event_node_list
> 
> Hmm. Nothing found.
> 
> $ objdump --syms ausearch-checkpt.o | grep event_node_list
> 0040 g O .bss 0008 event_node_list
> 
> It's in the object file? In ausearch-checkpt.c we have #include "ausearch-
> checkpt.h which does not define it. That file has #include "ausearch-llist.h" 
> which does not define it. That file has #include "ausearch-common.h" which 
> does 
> define it as:
> 
> extern slist *event_node_list;
> 
> So, what appears to be happening is all these C files are creating a 
> definition 
> based on this and they don't even use this variable. It seems like they would 
> create a spot in their table *if and only if* it was referenced somewhere in 
> the code.  I'm not sure if this was intended but it will be a big problem for 
> everyone.
Use -save-temps and post the .i file.

An "extern blah blah blah" should not be doing that.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 Mass Rebuild

[Jeff Law]

On Mon, 2020-01-27 at 16:34 +0100, Jakub Jelinek wrote:
> On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote:
> > Hi all,
> > 
> > Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
> > Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
> > changes:
> > 
> > https://fedoraproject.org/wiki/Changes/GLIBC231
> > https://fedoraproject.org/wiki/Releases/32/ChangeSet#Binutils_2.33
> > https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
> > https://fedoraproject.org/wiki/Changes/golang1.14
> > https://fedoraproject.org/wiki/Changes/GCC10
> > https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0
> > 
> > we will start the mass rebuild on 2020-01-27
> 
> I thought the mass rebuild should be also for
> https://fedoraproject.org/wiki/LTOByDefault
> but the required changes AFAIK haven't landed into redhat-rpm-config yet.
> 
> CCing Jeff on the current state.
After finally starting looking at the LTO vs GDB issues last week, I
think we should defer LTO until F33.  There's just too many GDB
failures when used with LTO that aren't understood yet.

I have asked that the LTO bytecode stripping change get into redhat-
rpm-config immediately though.  We already know some packages have
enabled LTO and we want to make sure they don't leak the LTO bytecodes
into the distro.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re:gcc-10 Fortran argument mismatch issue

[Jeff Law]

On Tue, 2020-01-21 at 20:41 +, devel-
requ...@lists.fedoraproject.org wrote:
> --
> 
> Date: Tue, 21 Jan 2020 21:27:47 +0100
> From: Dominik 'Rathann' Mierzejewski 
> Subject: Re: gcc-10 Fortran argument mismatch issue
> To: devel@lists.fedoraproject.org
> Message-ID: <20200121202747.ga5...@sakura.greysector.net>
> Content-Type: text/plain; charset=utf-8
> 
> Hi, Jeff.
> 
> On Tuesday, 21 January 2020 at 21:16, Jeff Law wrote:
> > 
> > So this is another issue that's going to be seen with gcc-10.  I'd been
> > hoping to get the time to fix packages correctly, but I think it's
> > ultimately going to have to fall to the package maintainers.
> > 
> > gcc has traditionally allowed certain type mismatches for arguments in
> > Fortran code.   GCC would issue a diagnostic under -Wargument-mismatch
> > for these cases, but the issue was not considered fatal.
> > 
> > Starting with gcc-10, these are now fatal errors which look something
> > like this:
> > 
> > 
> > 
> > Error: Rank mismatch in argument ‘array’ at (1) (rank-1 and scalar)
> 
> Could you give some example(s) how to fix such errors? Is there an entry
> for this in the gcc-10 porting guide?
> 
> > While gcc-10 has an option to disable this diagnostic, the potential
> > for codegen issues in this space was significant enough that I didn't
> > think an opt-out or advertising magic flag workaround was advisable.
> > 
> > A partial list of the affected packages (generated back in October from
> > a partial run of my tester):
> 
> Are there any build logs with errors available?
Not easily for a variety of reasons.  We're working on that, but I
doubt it'll be ready during the F32 cycle.

But I can give you specific examples pretty easily.  wannier90 is
probably the best because there's a single instance and we know it's
already fixed in newer versions of wannier90.

> gfortran  -O2  -flto -ffat-lto-objects   -g -pipe -Wall 
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -fexceptions -fstack-protector-strong -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC 
> -c ../postw90/comms.F90
> f951: Warning: '-Werror=' argument '-Werror=format-security' is not valid for 
> Fortran
> ../postw90/comms.F90:893:29:
> 
>   893 | call my_icopy(localcount,rootglobalarray,1,array,1)
>   | 1
> Error: Rank mismatch in argument 'zx' at (1) (rank-1 and scalar)
What GCC is complaining about is argument types at the call site do not
match the arguments at the function definition.

In this case, at the call site "rootglobalarray" is a simple integer:

> integer, intent(inout):: rootglobalarray

Yet if we look at the definition of my_icopy, the corresponding
parameter (ZX) is an array.



subroutine my_ICOPY(N,ZX,INCX,ZY,INCY)
>   ! .. Scalar Arguments ..
>   integer INCX,INCY,N
>   ! ..
>   ! .. Array Arguments ..
>   integer ZX(*),ZY(*)


Thus the types at the call site do not match the types at the
definition site and gcc complains. 

Now if we look at wanner-3.0 from upstream we see the how this was
fixed.  

> integer, dimension(:), intent(inout)  :: rootglobalarray
> 

The type at the call site was changed to have an array type.  Note the
same fix was applied for the "array" argument at the call site (boy was
that horribly named!)

Note that I'm _not_ a Fortran guy, it's well out of my area of
expertise.  So while I could help here, particularly for trivial cases
like this, it's probably better for package owners to step in and own
fixing the Fortran packages.

The set of packages I know are affected by these kinds of issues based
on last week's builds:

arpack
cgnslib
cp2k
dl_poly
elk
elpa
exciting
ga
getdata
grib_api
hdf
libccp4
mpich
MUMPS
ncl
netcdf-fortran
psblas3
qrmumps
qrupdate
quantum-espresso
R
R-deldir
scalapack
scipy
scorep
wannier90
wsjtx
xfoil
xrotor



Jeff




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Re: gcc 10: Default to -fno-common, multiple definitions of ...

[Jeff Law]

> Date: Wed, 22 Jan 2020 07:34:01 -0600
> From: Justin Forbes 
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
>   ...
> To: Development discussions related to Fedora
>   
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> On Wed, Jan 22, 2020 at 5:42 AM Miro Hrončok  wrote:
> > On 22. 01. 20 12:33, Fabio Valentini wrote:
> > > On Wed, Jan 22, 2020 at 12:12 PM Kevin Kofler  
> > > wrote:
> > > > Miro Hrončok wrote:
> > > > > https://gcc.gnu.org/gcc-10/porting_to.html#common
> > > > > 
> > > > > "Default to -fno-common
> > > > > 
> > > > > A common mistake in C is omitting extern when declaring a global 
> > > > > variable
> > > > > in a header file. If the header is included by several files it 
> > > > > results in
> > > > > multiple definitions of the same variable. In previous GCC versions 
> > > > > this
> > > > > error is ignored. GCC 10 defaults to -fno-common, which means a linker
> > > > > error will now be reported. To fix this, use extern in header files 
> > > > > when
> > > > > declaring global variables, and ensure each global is defined in 
> > > > > exactly
> > > > > one C file. As a workaround, legacy C code can be compiled with 
> > > > > -fcommon.
> > > > > 
> > > > > 
> > > > > int x;  // tentative definition - avoid in header files
> > > > > 
> > > > > extern int y;  // correct declaration in a header file"
> > > > 
> > > > I fail to see how this kind of incompatible change that breaks hundreds 
> > > > of
> > > > packages (and certainly a lot more software out there) is an 
> > > > improvement.
> > > > 
> > > >  Kevin Kofler
> > > 
> > > Honestly, it would have been good to mention that GCC 10 contains such
> > > a breaking change, either on the GCC10 Change proposal wiki page, or
> > > in the FESCo ticket.
> > > Neither was the case. :(
> > > 
> > > Now we still don't have a publicly available list of broken packages
> > > (which, apparently, was known?) - can we please get the list?
> > > I don't care where, but adding a link to it to either the Change wiki
> > > page or the FESCo ticket would be great, so we can better deal with
> > > it.
> > 
> > This is what I got offlist.
> > 
> > "This was generated in early December.  There may be minor differences
> > due to package updates, deprecations, etc.  But this should be  95%
> > complete."
> > 
> The list is certainly incomplete. Kernel and kernel-tools are not on
> it, but don't build due to it.  And, the issues don't seem to be "due
> to updates" rather code that has been there for quite some time.
So to give everyone a bit of background on the tester.  It's primary
purpose is to identify GCC issues by building all the Fedora packages
with the weekly GCC development snapshot.

My time is limited, so to avoid digging into issues that aren't really
related to the GCC development snapshot under testing the process works
like this:

1. Build a package using the development snapshot (using mock and a
priority repo so that my GCC package is selected before the standard
tools).   If that build succeeds, then we're done and happy.

2. If the build in step #1 fails, then we try the build again, but this
time without the priority repo.  So we're building with the standard
Fedora tools.  If this build succeeds, then the package is considered
as failing and gets investigated as it's highly likely there's a GCC
bug that needs addressing.  However, if this control build also fails,
then there's a problem of some sort with the package itself or other
tools in the buildroot.  And given my time is limited and the purpose
of my tester is to find GCC development bugs, if the control build
fails, then it's not typically investigated.

Typically there's around ~500 packages that fail their control build at
any given time.  I know I've seen kernel and kernel-tools in that
bucket from time to time.

My logs don't go back far enough to know the state of kernel and
kernel-tools in early December when that list was generated.  In the
run with last week's GCC snapshot, both the kernel and kernel-tools
worked with gcc-10 (they failed LTO, but that's totally separate from
the common symbol issues we're discussing now).

Jeff





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: cjdns with gcc-10 in Fedora

[Jeff Law]

On Wed, 2020-01-22 at 22:03 +, devel-
requ...@lists.fedoraproject.org wrote:
> Send devel mailing list submissions to
>   devel@lists.fedoraproject.org
> 
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
>   devel-requ...@lists.fedoraproject.org
> 
> You can reach the person managing the list at
>   devel-ow...@lists.fedoraproject.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of devel digest..."
> 
> Today's Topics:
> 
>1. Re: gcc 10: Default to -fno-common, multiple definitions of ...
>   (Stephen John Smoogen)
>2. Re: gcc 10: Default to -fno-common, multiple definitions of ...
>   (Christoph Junghans)
>3. Re: gcc 10: Default to -fno-common, multiple definitions of ...
>   (Fabio Valentini)
>4. Re: gcc 10: Default to -fno-common, multiple definitions of ...
>   (Michael Cronenworth)
>5. Orphaning argyllcms (Richard Hughes)
> 
> 
> --
> 
> Date: Wed, 22 Jan 2020 15:30:45 -0500
> From: Stephen John Smoogen 
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
>   ...
> To: Development discussions related to Fedora
>   
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> On Wed, 22 Jan 2020 at 14:54, Christoph Junghans  wrote:
> > On Wed, Jan 22, 2020 at 4:42 AM Miro Hrončok  wrote:
> > > jtaylornetsniff-ng ocaml-lablgtk suricata
> > > junghans   gasnet
> > 
> > Sorry, how do I install gcc10 on Rawhide?
> > "dnf upgrade --advisory=FEDORA-2020-a165791b6f" doesn't seem to do it.
> > 
> > Christoph
> > 
> 
> Going from a similar discussion in #fedora-devel. There has been no
> current compose of rawhide so it can not be synced out of the mirror.
> In order to upgrade/install gcc10 you will need to  enable the local
> repo in mock or replicate it on your system.
> 
> 2020-01-21 18:33:05  fedora-32 is still at gcc-9.2.1, but I got an 
> em
> ail saying cjdns no longer builds with gcc-10.  How do I rebuild with gcc-10 
> to
> get this fixed?  I assume the goal is to get most packages ready for gcc-10 
> befo
> re upgrading rawhide.
> 2020-01-21 18:58:03  sdgathman: rawhide/f32 already has gcc-10... 
> the
> re just hasn't been a successfull rawhide compose syncing it out to mirrors. 
> You
>  can do scratch builds or you could enable the 'local' repo in mock to use 
> the k
> oji buildroot...
Note that cjdns, according to my tester, is building fine with gcc-10
with and without LTO enabled as Jan 18th.

I know there was a bug in GCC that Martin Sebor fixed on Jan 13th that
caused gcc-10 to issue a false positive out of bounds array index
warning that in turn caused cjdns to fail.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: gcc 10: Default to -fno-common, multiple definitions of

[Jeff Law]

On Tue, 2020-01-21 at 19:16 +0100, Miro Hrončok wrote:
> On 21. 01. 20 19:04, Jeff Law wrote:
> > > --
> > > 
> > > 
> > > Date: Tue, 21 Jan 2020 17:44:37 +
> > > From: Peter Robinson 
> > > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
> > >   ...
> > > To: l...@redhat.com, Development discussions related to Fedora
> > >   
> > > Message-ID:
> > >   
> > > Content-Type: text/plain; charset="UTF-8"
> > > 
> > > > > I proposed a change to redhat-rpm-config to handle this case by
> > > > allowing  package to add a single line to their .spec file to turn off
> > > > the new common symbol handling.  Igor rejected that change arguing that
> > > > the packages themselves should be fixed.
> > > 
> > > Ultimately yes they should be fixed, but giving a means of easily
> > > mitigating the problem while people work with upstream to fix the
> > > issues is also useful, it's been a problem for ever and expecting
> > > people to fix it in short order is problematic especially when they'll
> > > start to be deluged in FTBFS spam within moments of the mass rebuild.
> > That was the idea.   Provide a trivial opt-out so that upstreams had
> > time to fix properly.  I even volunteered to add the opt-out marker
> > where appropriate to minimize the FTBFS issues.  I also volunteered to
> > help with the packages that don't honor flags injection.
> 
> This sounds reasonable to me.
> 
> The PR is https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77
> 
> I have reopened it.
> 
> The mass rebuild will notify the maintainrs and they can use that macro to 
> short-workaround the problem. It' also easier to grep from the specs than 
> custom 
> patches and whatnots.
Yes, the ability to inspect a .spec file for "violations" was also a
benefit -- both in terms of what packages are in need of TLC WRT common
symbol handling and in terms of finding packages that are not honoring
flags injection.

So the question is who makes the final call WRT the change to redhat-
rpm-config, particularly given Igor's position?

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: gcc 10: Default to -fno-common, multiple definitions of ...

[Jeff Law]

> Date: Tue, 21 Jan 2020 14:00:30 +0100
> From: Miro Hrončok 
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
>   ...
> To: devel@lists.fedoraproject.org, Jakub Jelinek 
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> On 21. 01. 20 13:47, Jakub Jelinek wrote:
> > On Tue, Jan 21, 2020 at 01:42:25PM +0100, Fabio Valentini wrote:
> > > I've seen this issue pop up in some other packages, as well.
> > > 
> > > My elementary-files package is affected, and I think it broke
> > > rubygem-ffi, too (which is blocking the ruby 2.7 rebuild, breaking a
> > > lot of ruby packages; though I can't access the build log for the
> > > failed rubygem-ffi build, due to a koji bug relating to side tags).
> > 
> > Yes, it should affect around 400 packages in the distro from what I remember
> > from Jeff's test mass rebuild
> 
> Can you please share the list? I'd liek to now how many Python packages are 
> there and analyze whether extension modules built with distutils are affected 
> or 
> not.
Sent offlist.  Happy to provide to anyone that wants the data, but
didn't figure everyone would want it on devel@.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: gcc 10: Default to -fno-common, multiple definitions of ...

[Jeff Law]

On Tue, 2020-01-21 at 13:47 +0100, Jakub Jelinek wrote:
> On Tue, Jan 21, 2020 at 01:42:25PM +0100, Fabio Valentini wrote:
> > I've seen this issue pop up in some other packages, as well.
> > 
> > My elementary-files package is affected, and I think it broke
> > rubygem-ffi, too (which is blocking the ruby 2.7 rebuild, breaking a
> > lot of ruby packages; though I can't access the build log for the
> > failed rubygem-ffi build, due to a koji bug relating to side tags).
> 
> Yes, it should affect around 400 packages in the distro from what I remember
> from Jeff's test mass rebuild, other distros are aware of it too and the
> fixes just need to be pushed upstream or grabber from upstream if they are
> there already.
> Adding -fcommon is a temporary workaround but fixing the packages is
> preferred, especially if those fixes end up upstream.
Right.  It was ~450.   The SuSE team in particular has had reasonable
success getting fixes upstreamed -- I think Martin L indicated they'd
gotten a few dozen fixed upstream.

ISTM that fixing upstream is by far the best choice followed by fixing
with a Fedora patch.  Working around via an opt-out or modifying the
flags in a .spec file is the least desirable.

Jeff


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

gcc-10 Fortran argument mismatch issue

[Jeff Law]

So this is another issue that's going to be seen with gcc-10.  I'd been
hoping to get the time to fix packages correctly, but I think it's
ultimately going to have to fall to the package maintainers.

gcc has traditionally allowed certain type mismatches for arguments in
Fortran code.   GCC would issue a diagnostic under -Wargument-mismatch
for these cases, but the issue was not considered fatal.

Starting with gcc-10, these are now fatal errors which look something
like this:



Error: Rank mismatch in argument ‘array’ at (1) (rank-1 and scalar)



While gcc-10 has an option to disable this diagnostic, the potential
for codegen issues in this space was significant enough that I didn't
think an opt-out or advertising magic flag workaround was advisable.

A partial list of the affected packages (generated back in October from
a partial run of my tester):

R-deldir
R
atlas
cgnslib
cp2k
elk
elpa
exciting
ga
getdata
grib_api
hdf
libccp4
mpich
hwchem
psblas3
qrmumps
qrupdate
quantum-espresso
scalapack
scipy
scorep
wannier90
wsjtx
xfoil
xrotor


One of the upstream GCC developers looked at wannier90.  It turns out
we're using a fairly old version (2.0.1, 2015).  Newer versions (3.0
Feb 2019) already have this problem fixed.

So consider this a heads-up that roughly 30-40 Fortran packages are
going to start failing.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: gcc 10: Default to -fno-common, multiple definitions of ...

[Jeff Law]

> 
> 
> 
> Date: Tue, 21 Jan 2020 11:05:37 -0500
> From: Steve Grubb 
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
>   ...
> To: devel@lists.fedoraproject.org
> Cc: Jakub Jelinek 
> Message-ID: <4127758.jL2Gs7s9Fr@x2>
> Content-Type: text/plain; charset="UTF-8"
> 
> On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote:
> > This is a known thing in gcc 10:
> > 
> > https://gcc.gnu.org/gcc-10/porting_to.html#common
> > 
> > "Default to -fno-common
> > 
> > A common mistake in C is omitting extern when declaring a global variable
> > in a header file. If the header is included by several files it results in
> > multiple definitions of the same variable. In previous GCC versions this
> > error is ignored. GCC 10 defaults to -fno-common, which means a linker
> > error will now be reported. To fix this, use extern in header files when
> > declaring global variables, and ensure each global is defined in exactly
> > one C file. As a workaround, legacy C code can be compiled with -fcommon.
> > 
> > 
> >int x;  // tentative definition - avoid in header files
> > 
> >extern int y;  // correct declaration in a header file"
> 
> So, for those of us using F31 as the development / test environment, is there 
> a macro that we can add -fno-common to in ~/.rpmmacros without placing it in 
> the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ?
> 
> Looking for an easy way to reproduce this without modifying root owned files.
> 
> -Steve
> 
> 
> --
> 
> Date: Tue, 21 Jan 2020 17:27:20 +0100
> From: Miro Hrončok 
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
>   ...
> To: Steve Grubb , devel@lists.fedoraproject.org
> Message-ID: <0f655139-44f5-a0c5-b600-66614c8bd...@redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> On 21. 01. 20 17:05, Steve Grubb wrote:
> > On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote:
> > > This is a known thing in gcc 10:
> > > 
> > > https://gcc.gnu.org/gcc-10/porting_to.html#common
> > > 
> > > "Default to -fno-common
> > > 
> > > A common mistake in C is omitting extern when declaring a global variable
> > > in a header file. If the header is included by several files it results in
> > > multiple definitions of the same variable. In previous GCC versions this
> > > error is ignored. GCC 10 defaults to -fno-common, which means a linker
> > > error will now be reported. To fix this, use extern in header files when
> > > declaring global variables, and ensure each global is defined in exactly
> > > one C file. As a workaround, legacy C code can be compiled with -fcommon.
> > > 
> > > 
> > > int x;  // tentative definition - avoid in header files
> > > 
> > > extern int y;  // correct declaration in a header file"
> > 
> > So, for those of us using F31 as the development / test environment, is 
> > there
> > a macro that we can add -fno-common to in ~/.rpmmacros without placing it in
> > the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ?
> > 
> > Looking for an easy way to reproduce this without modifying root owned 
> > files.
> 
> You should be able to redefine %__global_compiler_flags in ~/.rpmmacros.
> It still means you need to copy paste the current flags, but you won't need 
> to 
> touch root owned files.
I proposed a change to redhat-rpm-config to handle this case by
allowing  package to add a single line to their .spec file to turn off
the new common symbol handling.  Igor rejected that change arguing that
the packages themselves should be fixed.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: gcc 10: Default to -fno-common, multiple definitions of

[Jeff Law]

> 
> --
> 
> 
> Date: Tue, 21 Jan 2020 17:44:37 +
> From: Peter Robinson 
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
>   ...
> To: l...@redhat.com, Development discussions related to Fedora
>   
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> > > I proposed a change to redhat-rpm-config to handle this case by
> > allowing  package to add a single line to their .spec file to turn off
> > the new common symbol handling.  Igor rejected that change arguing that
> > the packages themselves should be fixed.
> 
> Ultimately yes they should be fixed, but giving a means of easily
> mitigating the problem while people work with upstream to fix the
> issues is also useful, it's been a problem for ever and expecting
> people to fix it in short order is problematic especially when they'll
> start to be deluged in FTBFS spam within moments of the mass rebuild.
That was the idea.   Provide a trivial opt-out so that upstreams had
time to fix properly.  I even volunteered to add the opt-out marker
where appropriate to minimize the FTBFS issues.  I also volunteered to
help with the packages that don't honor flags injection.

> 
> It might also be handy for there to be a heads up bug when the
> toolchain team first discovers these sorts of issues to give a longer
> runway for people to be able to engage with upstream to get a fix.
I contacted ffesti about 6 weeks ago -- shortly after the commit went
upstream GCC and I'd consulted with the SuSE engineers about how they
were planning to handle this situation.  Sadly I got no response
whatsoever from ffesti.

Jeff



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: gcc 10: Default to -fno-common, multiple definitions of

[Jeff Law]

On Tue, 2020-01-21 at 13:33 -0500, Steve Grubb wrote:
> On Tuesday, January 21, 2020 1:16:00 PM EST Miro Hrončok wrote:
> > > > > > I proposed a change to redhat-rpm-config to handle this case by
> > > > > 
> > > > > allowing  package to add a single line to their .spec file to turn off
> > > > > the new common symbol handling.  Igor rejected that change arguing 
> > > > > that
> > > > > the packages themselves should be fixed.
> > > > 
> > > > Ultimately yes they should be fixed, but giving a means of easily
> > > > mitigating the problem while people work with upstream to fix the
> > > > issues is also useful, it's been a problem for ever and expecting
> > > > people to fix it in short order is problematic especially when they'll
> > > > start to be deluged in FTBFS spam within moments of the mass rebuild.
> > > 
> > > That was the idea.   Provide a trivial opt-out so that upstreams had
> > > time to fix properly.  I even volunteered to add the opt-out marker
> > > where appropriate to minimize the FTBFS issues.  I also volunteered to
> > > help with the packages that don't honor flags injection.
> > 
> > This sounds reasonable to me.
> > 
> > The PR is
> > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77
> > 
> > I have reopened it.
> > 
> > The mass rebuild will notify the maintainrs and they can use that macro to
> > short-workaround the problem. It' also easier to grep from the specs than
> > custom patches and whatnots
> 
> I need something like this for suricata. It has about 45 variables causing 
> this. And it's not a simple "extern" addition because it looks like in many 
> cases the variable was never placed in a C file. Simply adding extern keyword 
> leads undefined reference errors. This will take a while to sort out with 
> upstream.
You also have to be careful if you're building shared libraries -- I
was looking at a package (I forget which) which built multiple DSOs. 
If you're not careful you can end up with some DSOs which wouldn't have
the definition -- worse yet, you're not going to get an undefined
symbol when you build those DSOs.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: GCC10

[Jeff Law]

On Thu, 2020-01-02 at 19:48 +, devel-
requ...@lists.fedoraproject.org wrote:
> Date: Thu, 2 Jan 2020 12:52:03 -0500
> From: Kaleb Keithley 
> Subject: Re: Fedora 32 System-Wide Change proposal: GCC10
> To: Development discussions related to Fedora
> 
> Message-ID:
> 
> Content-Type: multipart/alternative;
> boundary="6bf9f6059b2bdac6"
> 
> --6bf9f6059b2bdac6
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> 
> One (the only) thing I've noticed so far about gcc-10 is that (sloppily)
> defined variables in header files that lack an extern qualifier and that
> don't have an explicit defn in a .c file are no longer 'common' or .comm
> but are now .global .bss and cause link errors due to duplicate definitions=
> .
> 
> This very well might be because I made a mistake in the way I built gcc-10.
> I'm not sure I have any way to know.
> 
> If it's not a mistake on my part then this change has revealed a few bugs
> in the other applications that I work on.
> 
> These bugs should be fixed of course, but it's something to be aware of
> when considering a major change like this, this late in the f32/rawhide
> development cycle. Almost certainly a lot of other things will have similar
> bugs.
This is a known and desirable change in the compiler.

GCC-10 defaults to -fno-common for C which is a change relative to gcc-
9 (C++ has been -fno-common for eons, possibly forever).  You really
should get your sources fixed to adhere to modern C standards.


This affects ~450 packages in Fedora, openSUSE and other distributions.
I have already reached out to ffesti  (without a response :( to get an
opt-out mechanism for redhat-rpm-config that would broken packages to
opt-out of this behavior.

jeff


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: The case of LTO when produced enlarged binaries

[Jeff Law]

On Sun, 2020-08-30 at 14:42 +0200, Igor Raits wrote:
> On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote:
> > On Fri, 24 Jul 2020 at 21:31, Igor Raits <
> > ignatenkobr...@fedoraproject.org>
> > wrote:
> > [..]
> > 
> > > Well, I tell what I see :)
> > > 
> > > Compiling kitty with settings below produces this big
> > > /usr/lib64/kitty/kitty/fast_data_types.so:
> > > 
> > > * Without any LTO-related flags: 4.52 MB
> > > * With -flto: 4.30 MB
> > > * With -flto -ffat-lto-objects: 4.79 MB
> > > 
> > > Well, I did not run compilation multiple times but don't think it
> > > will
> > > change much.
> > > 
> > 
> > Comparing the size of the executable files does not make any sense.
> > You should use the "size" command.
> 
> Well, I'd use `size` command if I would care what section of a file
> takes what size. In this case, I don't really care which section it is.
> 
> All I care is that with -ffat-lto-objects, binary becomes bigger.
Given this isn't a correctness issue, I haven't prioritized it.

A quick look tells me all the difference is in the symbol table -- ie, the code,
data and bss sections are the same size, but the symbol table is significantly
larger.  And AFAICT it's all debug symbols.

In fact, it doesn't look like the debug info was stripped at all:

[law@localhost kitty]$ objdump -h fast_data_types.so

fast_data_types.so: file format elf64-x86-64
[ ... ]
 26 .debug_aranges 01e0      000e2b64  2**0
  CONTENTS, READONLY, DEBUGGING, OCTETS
 27 .debug_info   000e60c7      000e2d44  2**0
  CONTENTS, READONLY, DEBUGGING, OCTETS
 28 .debug_abbrev 7543      001c8e0b  2**0
  CONTENTS, READONLY, DEBUGGING, OCTETS
 29 .debug_line   0007644f      001d034e  2**0
  CONTENTS, READONLY, DEBUGGING, OCTETS
 30 .debug_str0005cab8      0024679d  2**0
  CONTENTS, READONLY, DEBUGGING, OCTETS
 31 .debug_loc000d6477      002a3255  2**0
  CONTENTS, READONLY, DEBUGGING, OCTETS
 32 .debug_ranges 0003a000      003796cc  2**0
  CONTENTS, READONLY, DEBUGGING, OCTETS
 33 .debug_macro  0002b64f      003b36cc  2**0
  CONTENTS, READONLY, DEBUGGING, OCTETS


So someone needs to figure out why debug symbols aren't being stripped.  I
manually stripped the bits in kitty and after doing so the sizes of the 
resultant
DSOs are the same (as I'd expect them to be) across the two builds.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: FYI Fedora 34 OCaml 4.11.1 rebuild

[Jeff Law]

On Tue, 2020-09-01 at 17:27 +0100, Richard W.M. Jones wrote:
> We did a Fedora 34 OCaml 4.11.0 rebuild a couple of weeks back,
> something like 170+ packages.  Well, a compiler bug was found and
> upstream released OCaml 4.11.1.  Details here:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1870368#c26
> 
> So I'm going to do a 4.11.1 build (into a side tag first).  I'm not
> expecting there to be any problems since we fixed all the build bugs
> mostly related to ocaml-dune and LTO so recently.
ACK.  If anything new pops up in the LTO space, please reach out.

JEff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: The case of LTO when produced enlarged binaries

[Jeff Law]

On Mon, 2020-08-31 at 09:17 +0200, Bob Mauchin wrote:
> 
> 
> On Mon, Aug 31, 2020, 05:32 Jeff Law  wrote:
> > On Sun, 2020-08-30 at 14:42 +0200, Igor Raits wrote:
> > > On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote:
> > > > On Fri, 24 Jul 2020 at 21:31, Igor Raits <
> > > > ignatenkobr...@fedoraproject.org>
> > > > wrote:
> > > > [..]
> > > > 
> > > > > Well, I tell what I see :)
> > > > > 
> > > > > Compiling kitty with settings below produces this big
> > > > > /usr/lib64/kitty/kitty/fast_data_types.so:
> > > > > 
> > > > > * Without any LTO-related flags: 4.52 MB
> > > > > * With -flto: 4.30 MB
> > > > > * With -flto -ffat-lto-objects: 4.79 MB
> > > > > 
> > > > > Well, I did not run compilation multiple times but don't think it
> > > > > will
> > > > > change much.
> > > > > 
> > > > 
> > > > Comparing the size of the executable files does not make any sense.
> > > > You should use the "size" command.
> > > 
> > > Well, I'd use `size` command if I would care what section of a file
> > > takes what size. In this case, I don't really care which section it is.
> > > 
> > > All I care is that with -ffat-lto-objects, binary becomes bigger.
> > Given this isn't a correctness issue, I haven't prioritized it.
> > 
> > A quick look tells me all the difference is in the symbol table -- ie, the 
> > code,
> > data and bss sections are the same size, but the symbol table is 
> > significantly
> > larger.  And AFAICT it's all debug symbols.
> > 
> > In fact, it doesn't look like the debug info was stripped at all:
> > 
> > [law@localhost kitty]$ objdump -h fast_data_types.so
> > 
> > fast_data_types.so: file format elf64-x86-64
> > [ ... ]
> >  26 .debug_aranges 01e0      000e2b64  
> > 2**0
> >   CONTENTS, READONLY, DEBUGGING, OCTETS
> >  27 .debug_info   000e60c7      000e2d44  
> > 2**0
> >   CONTENTS, READONLY, DEBUGGING, OCTETS
> >  28 .debug_abbrev 7543      001c8e0b  
> > 2**0
> >   CONTENTS, READONLY, DEBUGGING, OCTETS
> >  29 .debug_line   0007644f      001d034e  
> > 2**0
> >   CONTENTS, READONLY, DEBUGGING, OCTETS
> >  30 .debug_str0005cab8      0024679d  
> > 2**0
> >   CONTENTS, READONLY, DEBUGGING, OCTETS
> >  31 .debug_loc000d6477      002a3255  
> > 2**0
> >   CONTENTS, READONLY, DEBUGGING, OCTETS
> >  32 .debug_ranges 0003a000      003796cc  
> > 2**0
> >   CONTENTS, READONLY, DEBUGGING, OCTETS
> >  33 .debug_macro  0002b64f      003b36cc  
> > 2**0
> >   CONTENTS, READONLY, DEBUGGING, OCTETS
> > 
> > 
> > So someone needs to figure out why debug symbols aren't being stripped.  I
> > manually stripped the bits in kitty and after doing so the sizes of the 
> > resultant
> > DSOs are the same (as I'd expect them to be) across the two builds.
> > 
> > jeff
> 
> Is the file permission 0755? This is often a permission problem I encounter 
> while reviewing. 
It is, but I'm not sure that's the core issue.

brp-strip explictly filters out DSOs, so it won't strip the .so files.

We have brp-strip-shared, but its never called AFAICT.

I'm not sure what folks want to do here, but it's clearly broken and really
doesn't have anything to do with LTO.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and F33

[Jeff Law]

On 10/2/20 6:31 AM, Vitaly Zaitsev via devel wrote:

On 01.10.2020 22:48, Jeff Law wrote:

What you want to do to fix this is force -fPIC into the build flags.
That inhibits local symbol resolution and the copy relocs that are so
problematical for QT.  You can see examples of how to do this in the
clementine package.

Telegram Desktop already uses -fPIC:


You'll have to look at each and every .o file you generate in your 
build.  I bet you're going to find one or more that aren't compiled with 
PIC.



Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jeff Law]

On 9/30/20 3:50 AM, Jan Kratochvil wrote:
> On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
>> But the GCC community
>> doesn't really test that option and it's known to be broken with LTO.
> I haven't seen any GCC PR for -fdebug-types-section being broken with LTO.

 I'm not aware of one either.  But as Jakub has previously pointed out
debug-types-section is disabled when LTO is enabled.  I don't know the
details of why that is done.


>
> During one abigail diff I did not see any difference. I plan to run a full
> distribution abigail massrebuild+check as stated in the Change to exclude any
> possible incompatibilities. That would discover unfiled GCC problems with
> -fdebug-types-section.
>
> Also I do not see why fixing -fdebug-types-section should be anyhow difficult
> if the compiler can produce -fno-debug-types-section. I can also write
> postprocessor to get -fdebug-types-section if GCC is unable to do that.
> That would sure lose the -fdebug-types-section compilation time performance
> benefits.
>
>
>> And, not surprisingly, our team has had significant input on the options
>> we're using *and* the GCC implementation of those options.   We make
>> recommendations based on our experiences. That same experience would lead us
>> to recommending against -fdebug-types-section at this time.
> I think I have also some DWARF experience. Could you suggest what is wrong on
> -fdebug-types-section?

Your best bet is to discuss with Jakub and perhaps Jason.   They're far
more familiar with the debuginfo generation than I am.


>
>
>> It would certainly be good to improve the on-disk distro size.
> OK, going to file a Change to enable gcc -gz option (zlib section compression)
> as that will reduce on-disk *.debug size by 52.84%! Then we can disable both
> DWZ and -fdebug-types-section as those become pointless then.

Note Mark's reply in the other thread.  Section compression has
significant tradeoffs.


>
>
>> So the only paths forward I see are to either fix -fdebug-types-section or
>> improve dwz.
> And obviously much easier is to fix -fdebug-types-section than DWZ (if there
> are really any bugs in -fdebug-types-section, there are known bugs nobody
> wants to fix in DWZ).

I think you're making an unsubstantiated leap here.  Neither of us know
what's wrong with GCC LTO and debug-types-section and others are working
on dwz.


>
>
>> Putting my Red Hat hat on, I get pushback from PM on *any* size increases in
>> the RHEL space.
> When we start talking about RHEL (and CentOS) DWZ is completely pointless then
> as DWZ there saves only 0.28% of *-debuginfo.rpm (20MB of 7.2GB).
> Therefore approx. 0.14% of the distribution size.

Umm, we're fighting with PM these days over things in the 10M range. 
So, no it's not pointless.


>
>
>> As much as we'd like to be in a world were a 1% increase in distro
>> size doesn't matter, that's not the actual world we live in.
> Unfortunately DWZ cannot decrease RHEL size by that 1%.

I'm not asking it to.  I'm saying that sizes matter, even in cases where
you think they shouldn't. 


>
>
>> And our RHEL customers absolutey do care about the size of debuginfo
>> becuause it affects link times.
> System debuginfo format does not affect link times. Using DWZ during linking
> customer's applications definitely only increases linking time as it is an
> extra step. Not sure what do you talk about.

Most customers don't use dwz.  But they consume its output for the RPMs
that we provide.


Jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jeff Law]

On 10/4/20 2:48 PM, Jan Kratochvil wrote:
> On Tue, 29 Sep 2020 22:29:44 +0200, Mark Wielaard wrote:
>> I was just discussing that recently with the Hotspot Perf GUI
>> maintainer. And we concluded that if .debug files would be compressed
>> then we would need an uncompressed cache somewhere. The issue with
>> having the on-disk debuginfo files compressed is that for
>> debugger/tracing/profiling tools it incurs an significant
>> decompression time delay and extra memory usage. Especially for a
>> profiling tool that only needs to quickly get a little information it
>> is much more convenient to be able to simply mmap the .debug file,
>> check the aranges and directly jump to the correct DIE offset. See
>> e.g. https://github.com/KDAB/hotspot/issues/115
> First is is a marginal use case. For the GDB popular here I tested zlib on
> some IIRC 500MB+ .debug file and the startup time was 11.00s->12.45s
> = +13.20%. Given GDB takes minutes to print something on such .debug files the
> <2s larger startup does not matter.

I'm not sure it's that marginal.  It may not matter for GDB since I
don't think the bottleneck is likely the decompression.  It would
certainly matter for profiling and the like -- I'd probably argue that
dwarf is a terrible choice for those tools, but I don't see CTF as a
viable alternative though, so they're stuck in the dwarf world.


>
> And then all this is about zlib compression. Facebook has developed zstd which
> is much faster. Google says faster than reading the .debug files, on my
> machine both zstd and NVMe disk read are both 2GB/s. I expect btrfs has even
> in-memory cache for decompressed files but I have not checked it now as all
> the numbers I have collected have no effect here anyway.

Please, let's stop talking about btrfs here.  It's not useful.


However, I think it's perfectly valid to discuss zstd if folks wanted to
change the compression scheme for debug sections.  In fact, I'd claim
sticking with zlib, gzip,  bzip2, xz, 7z, etc is unwise.  The world has
moved and zstd seems like the place we should be.  In fact, we use it
for various things within GCC already.


Jeff



pEpkey.asc
Description: application/pgp-keys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: readelf seems broken in F33

[Jeff Law]

On 9/16/20 3:44 PM, Steve Grubb wrote:
> Hello,
>
> I was doing some binary analysis of files in F33 and have run across 
> something odd.
>
> readelf -s  /usr/sbin/auditd | grep GLIBC
>
> produces a lot of output like:
>
>182: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
> (3)
>184: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
> (3)
>185: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
> (3)
>186: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
> (3)
>187: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.3.2 
> (2)
>191: 0 FUNCGLOBAL DEFAULT  UND alarm@GLIBC_2.2.5 
> (3)
>194: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
> (3)
>195: 0 FUNCGLOBAL DEFAULT  UND close@GLIBC_2.2.5 
> (3)
>197: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
> (3)
>
> It's missing a lot of symbols. Is this something with readelf or an odd
> effect of the LTO changes?

Odd, I'm running F33 bits here and I get 159 symbols from running that
(out of 206 total symbols).


jeff




pEpkey.asc
Description: application/pgp-keys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: readelf seems broken in F33

[Jeff Law]

On 10/6/20 3:05 PM, Florian Weimer wrote:
> * Steve Grubb:
>
>> I was doing some binary analysis of files in F33 and have run across
>> something odd.
>>
>> readelf -s  /usr/sbin/auditd | grep GLIBC
>>
>> produces a lot of output like:
>>
>>182: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
>> (3)
>>184: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
>> (3)
>>185: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
>> (3)
>>186: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
>> (3)
>>187: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.3.2 
>> (2)
>>191: 0 FUNCGLOBAL DEFAULT  UND alarm@GLIBC_2.2.5 
>> (3)
>>194: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
>> (3)
>>195: 0 FUNCGLOBAL DEFAULT  UND close@GLIBC_2.2.5 
>> (3)
>>197: 0 FUNCGLOBAL DEFAULT  UND [...]@GLIBC_2.2.5 
>> (3)
>>
>> It's missing a lot of symbols. Is this something with readelf or an odd
>> effect of the LTO changes?
> This question looks familiar.
>
> It's a deliberate change to indicate truncation.  Use readelf -sW if you
> want to avoid it.  Truncation has been silent before, so it's necessary
> to educate users about readelf -W.

I think I may have used --wide in my test because I wanted to see more
info...


jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: ELF section/file compression

[Jeff Law]

On 10/6/20 3:59 PM, Mark Wielaard wrote:
> Hi,
>
> Changing subject because this has nothing to do with that Change
> Proposal anymore.
>
> On Tue, Oct 06, 2020 at 01:49:13PM -0600, Jeff Law wrote:
>> However, I think it's perfectly valid to discuss zstd if folks wanted to
>> change the compression scheme for debug sections.  In fact, I'd claim
>> sticking with zlib, gzip,  bzip2, xz, 7z, etc is unwise.  The world has
>> moved and zstd seems like the place we should be.  In fact, we use it
>> for various things within GCC already.
> Personally I must admit that I am not really a fan of using ELF
> section/file compression. It makes it impossible to simply mmap the
> data in or to quickly read just a tiny bit because you first have to
> decompress (and allocate new memory) for it. IMHO .debug files are no
> different from other ELF files for which we would also not do this. We
> can just use rpm package compression to reduce the distro distribution
> size, but we should not (re)compress the install/on-disk files. That
> will just mean programs will create an extra cache of uncompressed
> files they need to consult frequently.

I'm not taking a position on whether or not we compress sections.  My
position is that if we're compressing them, then zstd seems like a
better solution than the others mentioned.  I certainly understand the
desire to just mmap in the stuff and move on.


[ ... ]

Secondly you can use ELF section compression. The ELF spec leaves room
> for adding new compression algorithms. The Chdr struct(s) contain a
> ch_type which describes the algorithm. Currently only one is
> specified, but there is a lot of room for expansion:
>
> /* Legal values for ch_type (compression algorithm).  */
> #define ELFCOMPRESS_ZLIB1  /* ZLIB/DEFLATE algorithm.  */
> #define ELFCOMPRESS_LOOS0x6000 /* Start of OS-specific.  */
> #define ELFCOMPRESS_HIOS0x6fff /* End of OS-specific.  */
> #define ELFCOMPRESS_LOPROC  0x7000 /* Start of processor-specific.  */
> #define ELFCOMPRESS_HIPROC  0x7fff /* End of processor-specific.  */
>
> So you could propose something on gnu-g...@sourceware.org for a GNU
> extension or at generic-...@googlegroups.com for a generic ELF one.
> And then get the ELF processing tools to adopt the new compression
> type.

ohhh, I didn't know it was baked in at this level.  Yea, if we're going
to do section compression with zstd, then it's clearly best to get it
officially supported at the ABI level.


jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: GCC "-fparallel-jobs" up to ~1.9x speedup when compiling individual files in parallel

[Jeff Law]

On Tue, 2020-08-25 at 10:17 +0100, Daniel P. Berrangé wrote:
> On Sat, Aug 22, 2020 at 12:53:24PM +0200, Germano Massullo wrote:
> > I think soon we will have a big boost in Koji performances thanks to
> > Giuliano Belinassi and his work on addressing GCC parallelization
> > bottlenecks. According to Phoronix, compiling individual files in
> > parallel may have up to ~1.9x speedup:
> > https://www.phoronix.com/scan.php?page=news_item=GCC-fparallel-jobs-Patches
> 
> AFAICT, that is referring to parallelizing single file compilation to
> make use of multiple cores. That's only useful if the other cores on
> your host are otherwise idle.
Correct.  It's going to be most helpful when there's a large TU with many
functions and there's nothing else going on to keep the cores/threads busy.

> 
> In koji we use parallel make (or equivalent) so that multiple files
> are compiled in parallel. Thus most of the time all cores will be fully
> utilized.
RIght.  Except for those which override the parallel make flags because they're
missing dependencies.  But these are very much the exception, not the rule.

> IOW, don't get too excited by the x1.9 speedup claim. I doubt we'll
> see that in kojki except in niche scenarios where a project's build
> is bottlenecked by a serialization point on compiling one file.
Right.  Also note the code isn't accepted upstream yet.  I strongly suspect
there's going to be more work required to make what Guiuliano's work ready for
prime time.

On a positive note, my understanding from talking to Giuliano last year was that
he was trying to parallelize GCC itself which I thought was untractable for a
student project given the amount of unprotected global state.  Instead I think 
he
ended up using the LTO partitioning code to find TU split points, then feeds
those into distinct fork/exec'd copies of GCC which is a much simpler problem to
solve.

So there may be uses for his work.  Obviously the GCC team will continue to
monitor and if/when we think there's a change we should make for Fedora to
exploit Giuliano's work we'll propose it.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

LTO and F33

[Jeff Law]

So we're at a point where the F33 FTBFS issues related to LTO that I'm aware of
have been resolved (by opting the package out of LTO).   I still expect some LTO
issues will pop up as packages fix things like missing dependencies, cmake
macros, etc.  I continue to be available to investigate potential LTO issues, 
but
package maintainers will need to contact me as I'm not actively looking for new
LTO issues.

My focus is now turning to the packages with LTO opt-outs.  I'll be extracting
bug reports for upstream (primarily GCC), trying simple workarounds for old 
style
symbol versioning, identifying backports from upstream GCC that allow us to
remove LTO opt-outs and the like.  So there should be a trickle of opt-outs
removed, but otherwise should largely be invisible to the F33 release process.

I'd like to thank everyone involved for being patient while we worked through
various issues and I look forward to continuing to make incremental improvements
now that the bulk of the LTO work has landed.

jeff






___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and F33

[Jeff Law]

On Tue, 2020-08-18 at 17:21 +0100, Tomasz Kłoczko wrote:
> On Tue, 18 Aug 2020 at 16:12, Jeff Law  wrote:
> [..] 
> > My focus is now turning to the packages with LTO opt-outs.  I'll be 
> > extracting
> > bug reports for upstream (primarily GCC), trying simple workarounds for old 
> > style
> > symbol versioning, identifying backports from upstream GCC that allow us to
> > remove LTO opt-outs and the like.  So there should be a trickle of opt-outs
> > removed, but otherwise should largely be invisible to the F33 release 
> > process.
> 
> Do you have a current list of packages which are failing because of LTO?
> (My question is not about those packages which have already applied LTO 
> disable)
Yea, it's an empty list :-)

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: chromium/ffmpeg fails on aarch64 in F33+

[Jeff Law]

On Tue, 2020-08-18 at 17:26 -0400, Tom Callaway wrote:
> I don't know aarch64 assembly, but chromium (or more specifically, the ffmpeg 
> part of chromium) is failing on aarch64 on F33+ (everywhere else it is fine):
> 
> obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function 
> `ff_prefetch_aarch64':
> (.text+0x10): relocation truncated to fit: R_AARCH64_CONDBR19 against symbol 
> `ff_prefetch_aarch64' defined in .text section in 
> obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o
> 
> The relevant asm is short and has not seen any change in a while, so I'm 
> suspicious of the toolchain.
> 
> Any help is appreciated so we can get chromium security updates into F33+.
I would guess that there's either a conditional jump to an undefined label or to
a label that is too far away.

Toolchain?  Likely.  GCC is probably the most appropriate component.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Pinta failed to build on f33/armv7hl

[Jeff Law]

On Fri, 2020-08-14 at 12:03 +0200, Andrea Musuruane wrote:
> Hi guys,
>I tried to update pinta to the latest upstream version. It built fine 
> except than on f33/armv7hl:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/1530/49241530/build.log
> 
> I have no idea why. Can someone please help?
FWIW, it's not LTO :-)

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: fedora-review fails due to no annobin in mock

[Jeff Law]

On Wed, 2020-08-19 at 20:15 +, Artur Iwicki wrote:
> Recently (happened today and happened a month ago), whenever I try to run 
> fedora-review for a Review Request that includes a C/C++ program, the mock 
> build fails immediately due to gcc/g++ not being able to find the annobin 
> plugin.
> > cc1plus: fatal error: inaccessible plugin file plugin/annobin.so expanded 
> > from short plugin name annobin: No such file or directory
> 
> Downloading the SRPM of the package I want to review, adding "BuildRequires: 
> annobin" and running fedora-review on this modified SRPM works, though 
> obviously it's a rather tedious workaround.
> 
> Does anyone else have this problem, or should I be worried about something 
> being broken in my setup?
I suspect gcc doesn't have a requirement on annobin because the primary user is
for building Fedora itself, not for end-user builds.

But shouldn't annobin be showing up in your buildroots as part of the standard
buildroot setup?!?

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and F33

[Jeff Law]

On Thu, 2020-08-20 at 11:42 +0200, Vitaly Zaitsev via devel wrote:
> On 18.08.2020 17:12, Jeff Law wrote:
> > So we're at a point where the F33 FTBFS issues related to LTO that I'm 
> > aware of
> > have been resolved (by opting the package out of LTO).   I still expect 
> > some LTO
> > issues will pop up as packages fix things like missing dependencies, cmake
> > macros, etc.  I continue to be available to investigate potential LTO 
> > issues, but
> > package maintainers will need to contact me as I'm not actively looking for 
> > new
> > LTO issues.
> 
> I have an LTO issue on armv7 with libtgvoip package from RPM Fusion
> (currently fixed by opting out of LTO on ARMv7). Can you check this?
This is a relatively common issue that we've still got to analyze to see what's
really going on (though at this point I think signs point to a GCC bug).

I recommend disabling LTO for armv7hl via something like this:

%ifarch armv7hl
%define _lto_cflags %{nil}
%endif


That limits the opt-out just to armv7hl and is consistent with what we're doing
in the primary Fedora repos (which in turn makes it easy to scan for and revisit
once we fix upstream issues)

Thanks,
jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Galera FTBFS in f33, but same build passes in f32

[Jeff Law]

On Thu, 2020-08-27 at 14:21 +0200, Lukas Javorsky wrote:
> Hi folks,
> 
> I've run into the compilation problem in the Galera package
> This problem occurs only on f33 and higher tho.
> 
> Here is build performed on Fedora 32:  
> https://koji.fedoraproject.org/koji/taskinfo?taskID=50232504
> 
> And here is the same build, but on Fedora 33:  
> https://koji.fedoraproject.org/koji/taskinfo?taskID=50232498
> 
> Does anyone know what could cause this?
> It looks like something that changed in cc1plus or scons is causing this, so 
> if you had similar issue, please let me know.
I'm pretty confident this is a source level issue, not a problem with gcc or
scons.

If you look at the cpp output you'll find something like this:

# 130 "galera/tests/defaults_check.cpp" 3 4
   (
# 130 "galera/tests/defaults_check.cpp"
   it == map.end()
# 130 "galera/tests/defaults_check.cpp" 3 4
   ) ? _ck_assert_failed("galera/tests/defaults_check.cpp", 130, "Failure '"
# 130 "galera/tests/defaults_check.cpp"
   "it == map.end()"
# 130 "galera/tests/defaults_check.cpp" 3 4
   "' occurred" ,
# 130 "galera/tests/defaults_check.cpp"
   "Failed to insert KV pair: %s = %s", param.first.c_str(),
param.second.c_str()
# 130 "galera/tests/defaults_check.cpp" 3 4
   , __null) : _mark_point("galera/tests/defaults_check.cpp", 130)

# 131 "galera/tests/defaults_check.cpp"

Where ck_assert_failed is defined by /usr/include/check.h, which comes from
check-devel:
CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, int line,
const char *expr, const char *msg,
...) CK_ATTRIBUTE_NORETURN
CK_ATTRIBUTE_FORMAT(printf, 4, 5);


Which says argument 4 of the call to ck_assert_failed is a printf style 
argument.
 

THat argument is:

"Failed to insert KV pair: %s = %s", param.first.c_str()

Note two string format arguments (%s).  Yet there are 3 arguments
(param.first.c_str(), param.second.c_str(), __null

That's what the compiler is complaining about.  This all indicates either 
check.h
is broken or the sources using it are broken.  But it isn't a compiler or scons
issue.


jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jeff Law]

On 9/28/20 8:50 AM, Jan Kratochvil wrote:

On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote:

If you want to make -fdebug-types-sections the default you really
should work with the upstream GCC developers to figure out why they
don't want that.

I haven't seen that, according to Richard Biener from GCC
-fdebug-types-section is a normally supported GCC feature:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878#c6
I am aware only of Jakub Jelinek who is against -fdebug-types-section.
I should also state he is the author of DWZ.


-fdebug-types-section a supported option in the sense that it's in the 
compiler and we'll fix bugs in it when we can.  But the GCC community 
doesn't really test that option and it's known to be broken with LTO.  
With the move to LTO for F33 we'd need to fix whatever is broken with 
-fdebug-types-section (and I don't know precisely what that is) before 
we could even consider turning it on.


 Jakub has a ton of experience with debug info generation in GCC as 
well as with the dwarf standardization process and based on those 
experiences he thinks dwz is a technically better solution. You 
disagree.  I would strongly advise against hinting that Jakub is biased 
against -fdebug-types-section simply because he is the author of dwz.  
That just makes you look combative.




If GCC is unable to support such a trivial feature as -fdebug-types-section
then Fedora should really already switch to the standard compiler. It will
come sooner or later anyway. This deviation from standard tools just causes
continuous troubles such as:
[fesco] Issue #2020: Firefox is switching from gcc to clang/llvm
https://pagure.io/fesco/issue/2020#comment-671672


I don't think it argues for that *at all*.  Not even close.


I do think we want to bring GCC and LLVM to parity and remove the Fedora 
policy which favors GCC.  I've still got a TODO to write the actual 
changes for the Fedora packaging guidelines to make that happen.







Trying to override upstream defaults in Fedora without understanding why
upstream decided on the current defaults isn't a good idea IMHO.

You know very well Fedora already overrides upstream GCC defaults a lot:
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection


And, not surprisingly, our team has had significant input on the options 
we're using *and* the GCC implementation of those options.   We make 
recommendations based on our experiences. That same experience would 
lead us to recommending against -fdebug-types-section at this time.







And DWZ is even a project unrelated to GCC so calling for upstream defaults
would really call for dropping DWZ.


Again, I don't see that at all.  dwz is a separate and distinct step in 
the build process.  It's not overriding anything in the compiler at all.








I totally get that it is frustrating if you worked for a long time on a
new feature to support some DWARF constructs for lldb

It is in no way a feature as it does not bring any user visible improvement.
It is only a compatibility with marginally (0.1%) used file format with
disputable benefits.



and your aren't able to get the patches in shape to be accepted upstream.

That is a repeated lie I have never even suggested. LLDB is fine accepting my
DWZ patches. I understand you are used to difficulty of upstreaming patches in
GNU projects but that is not the case of LLVM. In fact LLDB is a completely
different world in accepting patches than GDB where it was taking me even 10+
years to get some patches accepted. For GDB you need to learn first how to do
the ancient ineffective and bug-prone coding practices, force yourself to
really execute them to become a global maintainer and only then you manage to
get patches checked in.

You are repeatedly trying to make it look as the problem is upstreaming DWZ
support. That is not any problem. The problem is the DWZ itself as it just
isn't worth the effort of supporting it in all the consumers.


But -fdebug-types-section isn't a viable alternative right now IMHO.




As I am repeating again and again I just find DWZ too complicated for both
production and consumption for so little gain (size reduction) it achieves.
So before I complicate the LLDB codebase by the DWZ support and make it
a catch-up game for Red Hat, Fedora and others forever (as Apple+Google is
never going to use DWZ and they know why) I am trying by this Change to save
a lot of time for everyone.

The years of engineering time I have already spent on DWZ and the years of
engineering time I will have to spend on its future maintenance and reworks
(for clang DWARF) could be better spent on improving the debugging experience.
We are no 

Re: LTO and F33

[Jeff Law]

On 9/30/20 7:39 AM, Robert-André Mauchin wrote:

On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote:

So we're at a point where the F33 FTBFS issues related to LTO that I'm aware
of

  have been resolved (by opting the package out of LTO).   I still expect

some LTO issues will pop up as packages fix things like missing
dependencies, cmake macros, etc.  I continue to be available to investigate
potential LTO issues, but package maintainers will need to contact me as
I'm not actively looking for new LTO issues.

My focus is now turning to the packages with LTO opt-outs.  I'll be
extracting

  bug reports for upstream (primarily GCC), trying simple

workarounds for old style symbol versioning, identifying backports from
upstream GCC that allow us to remove LTO opt-outs and the like.  So there
should be a trickle of opt-outs removed, but otherwise should largely be
invisible to the F33 release process.
I'd like to thank everyone involved for being patient while we worked
through

  various issues and I look forward to continuing to make

incremental improvements now that the bulk of the LTO work has landed.

jeff


I have an issue with both Clementine and Strawberry (a fork of Clementine)
in F33 and above, users reported that disabling LTO fixes the problem.


Can you run objdump -CR on the executable and send me the result 
privately?   That will be enough to verify its the same problem with the 
same solution as kstars.



Jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: F34 Change proposal: Debug Info LLDB Index (System-Wide change)

[Jeff Law]

On 9/30/20 2:56 AM, Jan Kratochvil wrote:

On Wed, 30 Sep 2020 02:00:52 +0200, Michel Alexandre Salim wrote:

On Tue, 2020-09-29 at 16:29 -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex
Currently the change will affect only packages using:
  %global toolchain clang
Those are currently only these packages being built by clang and
using
this %toolchain framework: dotnet3.1 libcxxabi mtxclient nheko simde
wine

FIXME: Which other Fedora packages are being built by clang?


Should this be mentioned as part of some packaging guidelines?
Especially as we expect more packages to use clang in the future.

As long as the .spec file uses
   %global toolchain clang
and the normal configuration variables %__cc %__cxx it all should work out of
the box. Unfortunately for example for libcxxabi it does not work out of the
box as overrides $CXXFLAGS somehow, I have to debug it.


Yea.  There's a variety of other packages that need the %toolchain bits, 
but aren't suffering too badly right now without it.  
american-fuzzy-lap, android-tools, clover2, hedgewars, & root are all in 
that position right now.  There may be others, that's just the set I 
know about because they're explicitly mucking around with LTO flags 
rather than getting them right automagically via %toolchain.





Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: F34 Change proposal: Debug Info LLDB Index (System-Wide change)

[Jeff Law]

On 9/30/20 2:33 AM, Jan Kratochvil wrote:

On Wed, 30 Sep 2020 02:11:34 +0200, Neal Gompa wrote:

Why don't you add an lldb-add-index tool to generate LLVM indexes for
LLDB?

Because doing it separately like GDB does is a wrong thing for
edit-compile-debug cycle. When clang (lld for LTO) has all the data incl. IR
already in memory it can much more faster produce the index for it.

With gdb-add-index it is questionable whether to use it or not for
edit-compile-debug cycles. If you run debugger just once for the compiled
program it is slower to generate + use the index just once than to run the
debugger without any index.

The index production performance does not matter much for rpmbuild as that
takes a long time anyway. But keeping the end-user edit-compile-debug cycle
unified with rpm build process makes the code path more tested and more
simple.


But there really isn't a edit-compile-debug cycle in play here -- so you 
may be right in the general case, but for RPM package builds it's a lot 
less clear.



It also seems to me that we would want the index regardless of the 
toolchain being used to build the executable or DSO.  I can't think of a 
good reason why someone who prefers lldb would have to suffer from worse 
performance because the system binary/library they need to debug was 
built with GCC.    And ISTM that if we want both index styles on all 
binaries and DSOs, then using the post-install step like lldb-add-index 
would make a lot more sense.



Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and F33

[Jeff Law]

On 9/30/20 10:20 AM, Vitaly Zaitsev via devel wrote:

On 30.09.2020 15:39, Robert-André Mauchin wrote:

I have an issue with both Clementine and Strawberry (a fork of Clementine)
in F33 and above, users reported that disabling LTO fixes the problem.

I have the same issue with Telegram Desktop:
https://bugzilla.redhat.com/show_bug.cgi?id=1880290


Ah, this isn't a Fedora package.  That's why it didn't show in Florian's 
symbol search or my dynamic relocation search.



What you want to do to fix this is force -fPIC into the build flags.  
That inhibits local symbol resolution and the copy relocs that are so 
problematical for QT.  You can see examples of how to do this in the 
clementine package.



jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and F33

[Jeff Law]

On 9/30/20 10:20 AM, Vitaly Zaitsev via devel wrote:

On 30.09.2020 15:39, Robert-André Mauchin wrote:

I have an issue with both Clementine and Strawberry (a fork of Clementine)
in F33 and above, users reported that disabling LTO fixes the problem.

I have the same issue with Telegram Desktop:
https://bugzilla.redhat.com/show_bug.cgi?id=1880290


ACK.  I'll verify it's the same issue and that the fix we're using for 
kstars, twinkle, etc works for the telegram desktop.



jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and F33

[Jeff Law]

On 9/30/20 9:25 AM, Zbigniew Jędrzejewski-Szmek wrote:

I pushed the following to fix build of sems:
https://src.fedoraproject.org/rpms/sems/c/beef747b4641429459065bd39dbea447405f33e9?branch=master
Not my package, and the code is a bit iffy, so it's quite likely that
the problem is in the package... Just letting you know in case you're still
looking for failures.


That is most likely a package issue that is just exposed by LTO. I'll 
take a look, but the QT singleton and gnulib regexp issues are higher 
priority right now.  It'll show up in my opt-out scanner, so that 
guarantees it won't be lost -- which is important as that diagnostic can 
be an indicator of a security issue and disabling LTO wouldn't change 
the underlying potential security issue.



Thanks,

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jeff Law]

On 9/29/20 5:59 PM, Neal Gompa wrote:


I feel like it's worth giving my perspective here as someone who has
done similar work in other distributions.


Thanks for that viewpoint.    As a compiler optimizer junkie, I don't 
really follow things on the RPM side, so hearing about that process has 
played out is useful.





For the record, Mark has started implementing DWARF-5 support in dwz:
https://sourceware.org/git/?p=dwz.git;a=log

I think I would rather like to see a Change proposal to switch to
DWARF-5 for Fedora 34, especially since it looks like dwz will be
ready for it.


Yea, I think moving to dwarf-5 would be a good step forward. ISTM we 
ought to do a test mass build with dwarf-5 by default. I'm currently 
testing some bits for other GCC developers, but ought to be able to do a 
dwarf-5 spin in a week or so to get a sense any notable fallout.



jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)

[Jeff Law]

On 9/30/20 6:50 AM, Mark Wielaard wrote:

Hi Neal,

On Tue, 2020-09-29 at 19:59 -0400, Neal Gompa wrote:

For the record, Mark has started implementing DWARF-5 support in dwz:
https://sourceware.org/git/?p=dwz.git;a=log

I think I would rather like to see a Change proposal to switch to
DWARF-5 for Fedora 34, especially since it looks like dwz will be
ready for it.

That is indeed my goal, but I wasn't planning on filing a specific
Change Proposal for it.

First because as you observed in the past we did some of these
debuginfo things Fedora first and then it took years (!) for some of
the default settings we had changed and helper scripts to make it
upstream. So I am concentrating on getting everything ready upstream
first before making and proposing any changes for Fedora.

Secondly I am hoping that because of the first point the GCC11 for
Fedora 34 Change Proposal will simply say "-gdwarf-5 is now the
default".


In that change proposal can you add a sentence or two in the proposal 
indicating that I will do a test rawhide build with gcc-11 with dwarf5 
on by default?  My worry is that once Aldy/Andrew's Ranger work has 
finished that I'll forget the need for dwarf5 testing.



jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and F33

[Jeff Law]

On 9/30/20 7:39 AM, Robert-André Mauchin wrote:

On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote:

So we're at a point where the F33 FTBFS issues related to LTO that I'm aware
of

  have been resolved (by opting the package out of LTO).   I still expect

some LTO issues will pop up as packages fix things like missing
dependencies, cmake macros, etc.  I continue to be available to investigate
potential LTO issues, but package maintainers will need to contact me as
I'm not actively looking for new LTO issues.

My focus is now turning to the packages with LTO opt-outs.  I'll be
extracting

  bug reports for upstream (primarily GCC), trying simple

workarounds for old style symbol versioning, identifying backports from
upstream GCC that allow us to remove LTO opt-outs and the like.  So there
should be a trickle of opt-outs removed, but otherwise should largely be
invisible to the F33 release process.
I'd like to thank everyone involved for being patient while we worked
through

  various issues and I look forward to continuing to make

incremental improvements now that the bulk of the LTO work has landed.

jeff


I have an issue with both Clementine and Strawberry (a fork of Clementine)
in F33 and above, users reported that disabling LTO fixes the problem.

The package builds but segfaults with:

Thread 1 "clementine" received signal SIGSEGV, Segmentation fault.
0x777f7e5b in void doActivate(QObject*, int, void**) () from 
/lib64/libQt5Core.so.5
(gdb) bt
#0  0x777f7e5b in void doActivate(QObject*, int, void**) () at 
/lib64/libQt5Core


[ ... ]

The backtrace doesn't contain the value of the arguments, but there's a 
very very good chance this is the same issue that I'm working on with 
kstars and twinkle.  We're getting multiple definitions of an object 
that's supposed to be a singleton.   If you've got a gdb session active, 
the following would give me enough to conclude it's the same issue.



x/i $pc        // Disassemble the current instruction

i r   // Dump register state


--




I'd suggest disabling LTO while we sort that issue out via

%define _lto_cflags %{nil}


In the .spec file.  That form of opt-out is flagged by my .spec file 
scanner and once we fix the issue I can easily go back, retest and turn 
LTO back on for those packages.



Jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 33 blocker status

[Jeff Law]

On 10/2/20 12:47 PM, Peter Robinson wrote:

On Fri, Oct 2, 2020 at 7:37 PM Jeff Law  wrote:


On 10/2/20 12:32 PM, Ben Cotton wrote:

Beta is out! Time to focus on Final blockers.

Action summary


Accepted blockers
-
1. firefox — Firefox not using langpacks for localization — ASSIGNED
ACTION: firefox maintainers to fix issue

2. sddm — login stuck when changing users repeatedly (log out, log in
a different one) — ASSIGNED
ACTION: kf5-kglobalaccel maintainers to provide systemd service file

3. gnome-control-center — Select Printer Driver hangs — POST
ACTION: none (waiting for coming upstream release)

   [ ... ]

Presumably it's still OK at this stage to fix obviously failing packages
in F33.  In particular I'm still working through the list of QT packages
that are running afoul of the symbol binding issues which in turn cause
those packages to segfault immediately at startup.

Yep, we don't freeze until next week and if they're submitted they may
well go stable before. Once we freeze unless they Blockers/Freeze
exceptions they'll just go our as zero days.


Just wanted to be sure.  I'm not usually involved in Fedora at this stage.


I've got ~50 packages still to investigate -- based on the ones I've 
looked at so only a small percentage will actually need rebuilding.  In 
the end I expect it'll be ~10 rebuilds for F33.



Jeff


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and F33

[Jeff Law]

On 10/2/20 6:31 AM, Vitaly Zaitsev via devel wrote:

On 01.10.2020 22:48, Jeff Law wrote:

What you want to do to fix this is force -fPIC into the build flags.
That inhibits local symbol resolution and the copy relocs that are so
problematical for QT.  You can see examples of how to do this in the
clementine package.

Telegram Desktop already uses -fPIC:


I would suggest looking for any uses of -fPIE when compiling the C/C++ 
sources.  PIE allows local binding for some object acceses (and again, 
its local binding of objects that runs afoul of key aspects of the QT 
libraries).



The package I've been looking at (nextcloud) has this gem in a couple of 
its CMakeLists.txt files:



 if(UNIX AND NOT APPLE)
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIE")
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIE")
  set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -pie")
 endif()

Which means we pass -fPIE when building .o files and thus the flag is 
ultimately passed through to LTO compiles which in turn enables the 
problematic symbol binding.  -fPIC is the right thing for QT 
applications given the way the library works.  Note that in the case of 
nextcloud, I don't think that was a global setting across the entire 
package -- it was used in just specific subdirectories and thus didn't 
show up in every invocation of the compiler.



Note that compiling the objects with -fPIC still allows creating a PIE 
executable via the -pie option at link time.  This is critically 
important from a security standpoint.


jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and F33

[Jeff Law]

On 10/2/20 10:01 AM, Jeff Law wrote:


On 10/2/20 6:31 AM, Vitaly Zaitsev via devel wrote:

On 01.10.2020 22:48, Jeff Law wrote:

What you want to do to fix this is force -fPIC into the build flags.
That inhibits local symbol resolution and the copy relocs that are so
problematical for QT.  You can see examples of how to do this in the
clementine package.

Telegram Desktop already uses -fPIC:


You'll have to look at each and every .o file you generate in your 
build.  I bet you're going to find one or more that aren't compiled 
with PIC.




So I've got a package which is exhibiting similar behavior.  It appears 
the objects are being compiled with the right PIC options, but I'm still 
getting local resolution and COPY relocs.  I'll update you once I know 
what's going on.


jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 33 blocker status

[Jeff Law]

On 10/2/20 12:32 PM, Ben Cotton wrote:

Beta is out! Time to focus on Final blockers.

Action summary


Accepted blockers
-
1. firefox — Firefox not using langpacks for localization — ASSIGNED
ACTION: firefox maintainers to fix issue

2. sddm — login stuck when changing users repeatedly (log out, log in
a different one) — ASSIGNED
ACTION: kf5-kglobalaccel maintainers to provide systemd service file

3. gnome-control-center — Select Printer Driver hangs — POST
ACTION: none (waiting for coming upstream release)


 [ ... ]

Presumably it's still OK at this stage to fix obviously failing packages 
in F33.  In particular I'm still working through the list of QT packages 
that are running afoul of the symbol binding issues which in turn cause 
those packages to segfault immediately at startup.



Jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

[Jeff Law]

On 10/23/20 8:01 AM, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 23 October 2020 at 14:45, Aleksandra Fedorova wrote:
> [...]
>> You can blame me for being not clear enough, if you want, but I'd
>> rather move on and use the current GCC11 work as an example which
>> shows the real power of the ELN proposal, and the real benefit for
>> Fedora which it brings.
>>
>> Despite the accusation of us bypassing the Fedora Change process, we
>> are doing a different thing.
>>
>> GCC11 will definitely go through the Change process as usual.
> That's reassuring.

Absolutely.

And as I've mentioned before on this thread, we're trying to figure out
how to drop that change in earlier than we have in the past.   There's
technical as well as non-technical concerns.  The time period Jakub and
myself were looking at was dropping it in at the end of stage1 upstream
gcc development which would be mid Nov.  But we both feel it's
imperative that the implications be discussed here and that the change
in procedure gets highlighted in the usual change proposal.


>> This activity could have been done internally in RHEL, or externally
>> in some upstream working groups. But ELN now allows us to do this work
>> in public in Fedora, and invite Fedora community to join it, if they
>> _want_.
> How can we join, then? How is this better than doing this, say, in COPR?
> Or a rawhide side-tag.

Right now the build is on a side tag and hasn't been merged into ELN (to
the best of my knowledge).  Once the bits are merged in then I expect
anyone can join in the "fun".


>
>> As we promised by the ELN Change we have provided the platform for GCC
>> upstream, RHEL downstream and Fedora community to collaborate on the
>> work for Fedora, and motivation for Red Hat to sponsor this effort.
> So far I haven't seen any clear instructions on how I can, say, rebuild
> my packages with GCC11 to catch any fall-out early. Or where you're
> going to publish (if at all) the results of any rebuilds you'll perform.
We don't generally publish them -- though we've certainly discussed it
in the past and the only impediment is my time.  The jenkins server
which drives my testing is on Red Hat's internal network, but there's a
publisher that would allow us to push the build info out to a public
facing server.  There's nothing inherently private and/or secret about
the work.  We also use that jenkins system to do wide scale testing of
GCC work before it lands in upstream GCC.


If you have specific packages in mind, I'm happy to let you know their
build status with gcc-11.  It's just some clicking.


jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

[Jeff Law]

On 10/23/20 5:55 AM, Clement Verna wrote:
>
>
> On Thu, 22 Oct 2020 at 14:28, Aleksandra Fedorova  > wrote:
>
> Hi, all,
>
> this is the informational message, no action required.
>
> Upon agreement between gcc maintainers and ELN SIG we would like to
> switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
>
> Though ELN is defined as the buildroot where Fedora Rawhide code is
> rebuilt into EL-like environment, in the ELN proposal we also
> mentioned that ELN can be used to test certain buildroot-related
> features on the side so it doesn't block Fedora Rawhide development.
>
> We think that GCC11 is one such feature, where we can benefit from
> testing it first on a small subset of the Fedora content in a separate
> environment.
>
>
> I think this is one of the great benefits of having ELN and being able
> to use it to start integrating such changes. I am looking forward,
> seeing if that makes it easier for GCC11 to land in rawhide, I would
> be nice if you could share the issues that were caught during that
> work in ELN.

We use the experiences found during Fedora builds to populate some of
the upstream GCC release documentation.  ie, what kinds of issues are we
seeing in real world code.  For example:


https://gcc.gnu.org/gcc-10/porting_to.html


There's a document for gcc-11 which has bullet items for things we've
seen in in our Fedora testing (and looking at it, there's a couple
things that need to be added :-).  But we haven't dropped in examples,
it's just the initial bullet list.

https://gcc.gnu.org/gcc-11/porting_to.html


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

[Jeff Law]

On 10/28/20 7:29 AM, Jonathan Wakely wrote:
> On 28/10/20 13:31 +0100, Florian Weimer wrote:
>> * Jonathan Wakely:
>>
>>> Dropping GCC 11 into rawhide now would mean I can't make certain
>>> ABI-breaking changes to the C++20 library in upstream GCC, because it
>>> would be landing on real users' machines. Which means I lose several
>>> weeks of GCC's stage 1 development. No thanks.
>>
>> This is for C++20 library support only, right?
>
> Right.
>
>> Not much software in Fedora uses the C++ standard library (even at older
>> C++ versions), so impact on Fedora itself should be limited.
>
> On Fedora iteself, yes. But not necessarily on users compiling their
> own code (or other third-party libraries) using the system compiler.
>
>> I can help you with diagnosing required ABI transitions and package
>> rebuilds.
>
> I'd rather just be able to change things freely during stage 1 :-)

The only thing on the table in the immediate term is to start dropping
gcc snapshots into rawhide after stage1 development closes -- ie mid
Nov.  So it shouldn't impact your desire to be able to break things
during gcc stage1 :-)


While I think we should seriously consider even earlier drops, that
would be in the gcc-12/F36 timeframe and would require a distinct change
proposal and I think it would be significantly more controversial.


Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 aarch64 build failures on copr

[Jeff Law]

On Wed, 2020-07-29 at 17:14 -0500, Brandon Nielsen wrote:
> On 7/29/20 4:40 PM, Jeff Law wrote:
> > ACK.  I don't see msp430-development-tools in the standard fedora repos.  
> > So I'll
> > leave it to you to fix the package in whatever repo it lives in.
> > 
> > Also note, you may ultimately be better off getting msp430 added to the 
> > cross-
> > {binutils,gcc} packages rather than creating a new package.
> > 
> > Jeff
> 
> It's a work in progress[0].
> 
> As for cross-gcc and friends, the description notes those are for 
> building kernels only, is that not the case?
It shouldn't matter for cross-binutils and cross-gcc.

> 
> There's also some vanilla upstream / TI upstream compatibility weirdness 
> to consider...
That issue should be resolved by getting those patches upstreamed to the GCC
project.  Your best contact point for that would be Jozef Lawrynowicz <
joze...@mittosystems.com>

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 aarch64 build failures on copr

[Jeff Law]

On Wed, 2020-07-29 at 14:24 -0500, Brandon Nielsen wrote:
> On 7/28/20 4:39 PM, Jeff Law wrote:
> > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
> > > On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law  wrote:
> > > > If this is a new failure (say in the last week), it could be an out
> > > > of memory
> > > > scenario.  Try disabling LTO.  The standard way to do that is
> > > > 
> > > > %define _lto_cflags %{nil}
> > > > 
> > > > In your %build stanza in the spec file.
> > > > 
> > > > Heff
> > > 
> > > I agree, it's almost certainly OOM because it says "fatal error:
> > > Killed." I've never seen that happen for any reason other than OOM.
> > I've seen it happen for a variety of reasons.  Please test with LTO 
> > disabled and
> > let me know if that helps.
> > 
> > jeff
> 
> Disabling LTO with '%define _lto_cflags %{nil}' fixed it.
ACK.  I don't see msp430-development-tools in the standard fedora repos.  So 
I'll
leave it to you to fix the package in whatever repo it lives in.

Also note, you may ultimately be better off getting msp430 added to the cross-
{binutils,gcc} packages rather than creating a new package.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Disable LTO for now ?

[Jeff Law]

On Wed, 2020-07-29 at 20:39 +0100, Sérgio Basto wrote:
> On Wed, 2020-07-29 at 12:19 -0500, Steven Munroe wrote:
> > Jeff Law wrote:
> > 
> > > For ppc64le is that the build was done with p8, but there is one
> > > function (__builtin_altivec_vadub) that requires p9. This seems
> > > like a package bug at first glance, not an LTO issue.
> > 
> > Yup __builtin_altivec_vadub is POWER9_VECTOR only.
> > 
> > For P8/6 use something like this:
> > 
> >   vmin = vec_min (a, b);
> >   vmax = vec_max (a, b);
> >   result = vec_sub (vmax, vmin);
> > 
> > executes in 4 cycles.
> 
> but why it built 18 day ago, opencv-4.3.0-7 [2],  
>  with same source code and rpm spec [1] ? 
All kinds of possibilities and speculating wouldn't be terribly helpful here.
 What remains is that there's code in there that requires p9, but the build is
specifying p8 only and thus you get an error.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

[Jeff Law]

On Mon, 2020-08-03 at 17:26 +0100, Daniel P. Berrangé wrote:
> On Mon, Aug 03, 2020 at 05:34:47PM +0200, Hans de Goede wrote:
> > Hi,
> > 
> > On 8/3/20 5:27 PM, Daniel P. Berrangé wrote:
> > > On Mon, Aug 03, 2020 at 05:01:18PM +0200, Florian Weimer wrote:
> > > > * Daniel P. Berrangé:
> > > > 
> > > > > Disabling LTO in the RPM spec confirms this and makes things pass
> > > > > again. Hacking the makefiles to remove the -fno-lto option when
> > > > > building the test suite binaries also fixes things.
> > > > > 
> > > > > I don't see any mention of LD_PRELOAD being impacted by LTO in the
> > > > > Fedora feature change page, but I can imagine how it would be.
> > > > 
> > > > LTO should still export the same functions as before, and should not
> > > > imply -fno-semantic-interposition by default.  The linker plugin
> > > > provides the necessary information to GCC.  What you are observing could
> > > > be the result of a toolchain bug.
> > > 
> > > Libvirt has a test program "qemuhotplugtest".
> > > 
> > > This test links to a shared library  libqemutestdriver.so which contains
> > > a function "qemuProcessStartManagedPRDaemon".
> > > 
> > > qemuhotplugtest test does not call "qemuProcessStartManagedPRDaemon"
> > > directly. It invokes "qemuDomainAttachDeviceDiskLive" which eventually
> > > ends up calling "qemuProcessStartManagedPRDaemon" some way further
> > > down the stack.
> > > 
> > > 
> > > Then there is a shared library libqemuhotplugmock.so which contains a
> > > replacement "qemuProcessStartManagedPRDaemon" to avoid us spawning
> > > external programs.
> > > 
> > > When it starts "qemuhotplugtest" will set LD_PRELOAD=libqemuhotplugmock.so
> > > and then execve() itself.
> > > 
> > > So when the test runs, the "qemuProcessStartManagedPRDaemon" impl from
> > > the mock library is supposed to be used.
> > > 
> > > If I run with LD_DEBUG=all on a build /without/ LTO, I can see this lookup
> > > and override happening:
> > > 
> > >  381018:  symbol=qemuProcessStartManagedPRDaemon;  lookup in 
> > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest
> > >  [0]
> > >  381018:  symbol=qemuProcessStartManagedPRDaemon;  lookup in 
> > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so
> > >  [0]
> > >  381018:  binding file 
> > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so
> > >  [0] to 
> > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so
> > >  [0]: normal symbol `qemuProcessStartManagedPRDaemon'
> > >  381018:  symbol=qemuProcessStartManagedPRDaemon;  lookup in 
> > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/lt-qemuhotplugtest
> > >  [0]
> > >  381018:  symbol=qemuProcessStartManagedPRDaemon;  lookup in 
> > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirhostdevmock.so
> > >  [0]
> > >  381018:  symbol=qemuProcessStartManagedPRDaemon;  lookup in 
> > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirpcimock.so
> > >  [0]
> > >  381018:  symbol=qemuProcessStartManagedPRDaemon;  lookup in 
> > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libdomaincapsmock.so
> > >  [0]
> > >  381018:  symbol=qemuProcessStartManagedPRDaemon;  lookup in 
> > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libvirprocessmock.so
> > >  [0]
> > >  381018:  symbol=qemuProcessStartManagedPRDaemon;  lookup in 
> > > file=/home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so
> > >  [0]
> > >  381018:  binding file 
> > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemutestdriver.so
> > >  [0] to 
> > > /home/berrange/src/fedora/libvirt/libvirt-6.5.0/x86_64-redhat-linux-gnu/tests/.libs/libqemuhotplugmock.so
> > >  [0]: normal symbol `qemuProcessStartManagedPRDaemon'
> > > 
> > > 
> > > If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups
> > > at all for qemuProcessStartManagedPRDaemon. It looks very much like the
> > > call was resolved and bound at link time when built with LTO.
> > 
> > Maybe it was not bound at link time, but inlined at compile time?
> > 
> > I think it might be worthwhile to try and mark the 
> > qemuProcessStartManagedPRDaemon
> > implementation which is used normally (no LD_PRELOAD) with some function
> > attribute that it may be never inlined. I'm sure Florian and/or Jakub
> > can help with what that function attribute should actually look like...
> 
> We usually mark APIs we mock with G_GNUC_NO_INLINE to prevent such
> problems. In this case we 

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Sat, 2020-08-01 at 12:12 +0200, Kevin Kofler wrote:
> Hi,
> 
> seeing the amount of fallout from LTO, I really think that this feature 
> ought to be dropped from F33, and evaluated carefully for F34 (i.e., can it 
> be done without breaking the build of or miscompiling a large part of the 
> distribution, once the bugs such as the ld bug discussed in this thread are 
> fixed, or is it just unsafe to enable by default to begin with?). I.e., 
> revert it for F33 for sure, then decide whether to retry it for F34 or can 
> it permanently.
Most of the fallout has been Nick pushing through binutils builds that are
broken.  Seriously, there's been at least 4 builds pushed through that kept
bringing back the *same* problem.

And just to be clear, this has been 6+ months of behind the scenes work to find
and identify issues, fix broken packages, put global mitigations of broken crap
in place in place, opt-out packages that do things that are fundamentally
incompatible with LTO, etc.  In fact it was that behind-the-scenes work that
pushed this feature from F32 to F33 as it just wasn't ready to go in F32.

I think the chances of a serious mis-compilation large parts of the distribution
are small.  The one mis-compilation we know about was a latent linker bug that
just happened to be triggered by LTO and that particular bug we know how to
identify any packages that might have been broken.

Frankly, there's been more fallout from infrastructure breakage and cmake issues
than anything.  I went through the first ~1000 failures proactively looking for
things that were potentially LTO related and fixing them half-dozen or so I
found, but by far the s390 infrastructure and cmake changes have caused more
failures than anything.

As has always been the case, I'm here to address any problems that arise and use
my 30 years of experience with GCC development as well as distribution mass
rebuilds to make informed decisions about the best course of action for any
particular problem.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Sat, 2020-08-01 at 12:34 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote:
> > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > > > Looks like it's in the buildroots now.  Let me know if that doesn't fix 
> > > > the
> > > > problem.
> > > 
> > > Looks as if "ar" is segfaulting again ...
> > > 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> > > https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> > > 
> > > That was built with binutils 2.35-8.fc33
> > Just an FYI binutils-2.35-9 is in the buildroots.  It's got the fix for the 
> > LTO
> > issue, but does not turn on LTO for binutils itself (that'll be in the -10
> > build).
> > 
> > I've confirmed that the -9 build will correctly build binutils-2.35-10.  
> > I've
> > also confirmed that the -9 build will correctly build libguestfs.
> > 
> > I'm going to take my local -10 build and use that to build libguestfs as an
> > additional sanity check.
> 
> Can confirm that libguestfs has been built correctly and is working (with 
> LTO).
> 
> FYI I filed this bug about LTO and inheriting warnings in functions
> inlined across files:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407
Yes, that's by design.  Conceptually the compiler doesn't really know that the
pragma refers to any particular function since they don't appear in any function
scope.   ASMs outside function scope have similar issues.

You could try moving the pragmas into function scope.  I've had some success 
with
that, but not as much as I'd like.  SuSE just disables all the warnings except
those which are emitted by the front-end.  I think that's a long term mistake,
but I don't have much influence over that decision.


Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Sat, 2020-08-01 at 21:00 +0100, Richard W.M. Jones wrote:
> On Sat, Aug 01, 2020 at 01:28:09PM -0600, Jeff Law wrote:
> > On Sat, 2020-08-01 at 12:34 +0100, Richard W.M. Jones wrote:
> > > On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote:
> > > > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> > > > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > > > > > Looks like it's in the buildroots now.  Let me know if that doesn't 
> > > > > > fix the
> > > > > > problem.
> > > > > 
> > > > > Looks as if "ar" is segfaulting again ...
> > > > > 
> > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> > > > > https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> > > > > 
> > > > > That was built with binutils 2.35-8.fc33
> > > > Just an FYI binutils-2.35-9 is in the buildroots.  It's got the fix for 
> > > > the LTO
> > > > issue, but does not turn on LTO for binutils itself (that'll be in the 
> > > > -10
> > > > build).
> > > > 
> > > > I've confirmed that the -9 build will correctly build binutils-2.35-10. 
> > > >  I've
> > > > also confirmed that the -9 build will correctly build libguestfs.
> > > > 
> > > > I'm going to take my local -10 build and use that to build libguestfs 
> > > > as an
> > > > additional sanity check.
> > > 
> > > Can confirm that libguestfs has been built correctly and is working (with 
> > > LTO).
> > > 
> > > FYI I filed this bug about LTO and inheriting warnings in functions
> > > inlined across files:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407
> > Yes, that's by design.  Conceptually the compiler doesn't really know that 
> > the
> > pragma refers to any particular function since they don't appear in any 
> > function
> > scope.   ASMs outside function scope have similar issues.
> > 
> > You could try moving the pragmas into function scope.
> 
> I'm not sure exactly what you mean, but this doesn't work (same
> error as before):
> 
> --- test.c ---
> 
> #include 
> 
> int
> test (int i)
> {
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wstack-usage="
> 
>   char str[i];
>   memset (str, 0, sizeof str);
>   return str[0]+i;
> 
> #pragma GCC diagnostic pop
> }
Yea, that's precisely what I meant and precisely what I feared wouldn't work 
(I'd
tried it with one of mjw's packages trying to address the same issue).  Nor will
it work if you move the pragmas so that they enclose the call site where test
gets inlined.

Given this works with other warnings, I wonder if there's some unexpected
implementation detail with -Wstack-usage= on the GCC side.  I'll look at it next
week.

jeff


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: postgis LTO failure

[Jeff Law]

On Sun, 2020-08-02 at 00:36 +0200, Sandro Mani wrote:
> Hi
> 
> postgis seems another one suffering from LTO related failures.
> 
> LTO (results in test failures): 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48393090
> 
> LTO disabled (tests pass): 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48394173
Thanks.  I'll take a look, but note that I've never managed to get postgis to
build with or without LTO.  It complains with an odd error:

make[1]: *** [Makefile:177: liblwgeom.la] Error 139
make[1]: Leaving directory '/builddir/build/BUILD/postgis-3.0.1/liblwgeom'
make: *** [GNUmakefile:20: all] Error 1

There's nothing else useful in the logs that I see.  But again, I'll take a look
and see if I can figure out what's going on.  In the mean time, feel free to go
ahead and disable LTO as I can't currently give any guidance on what might be
going wrong.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Sat, 2020-08-01 at 15:26 -0700, Kevin Fenzi wrote:
> On Sat, Aug 01, 2020 at 02:03:40PM -0600, Jeff Law wrote:
> > On Sat, 2020-08-01 at 12:12 +0200, Kevin Kofler wrote:
> > > Hi,
> > > 
> > > seeing the amount of fallout from LTO, I really think that this feature 
> > > ought to be dropped from F33, and evaluated carefully for F34 (i.e., can 
> > > it 
> > > be done without breaking the build of or miscompiling a large part of the 
> > > distribution, once the bugs such as the ld bug discussed in this thread 
> > > are 
> > > fixed, or is it just unsafe to enable by default to begin with?). I.e., 
> > > revert it for F33 for sure, then decide whether to retry it for F34 or 
> > > can 
> > > it permanently.
> > Most of the fallout has been Nick pushing through binutils builds that are
> > broken.  Seriously, there's been at least 4 builds pushed through that kept
> > bringing back the *same* problem.
> > 
> > And just to be clear, this has been 6+ months of behind the scenes work to 
> > find
> > and identify issues, fix broken packages, put global mitigations of broken 
> > crap
> > in place in place, opt-out packages that do things that are fundamentally
> > incompatible with LTO, etc.  In fact it was that behind-the-scenes work that
> > pushed this feature from F32 to F33 as it just wasn't ready to go in F32.
> > 
> > I think the chances of a serious mis-compilation large parts of the 
> > distribution
> > are small.  The one mis-compilation we know about was a latent linker bug 
> > that
> > just happened to be triggered by LTO and that particular bug we know how to
> > identify any packages that might have been broken.
> > 
> > Frankly, there's been more fallout from infrastructure breakage and cmake 
> > issues
> > than anything.  I went through the first ~1000 failures proactively looking 
> > for
> > things that were potentially LTO related and fixing them half-dozen or so I
> > found, but by far the s390 infrastructure and cmake changes have caused more
> > failures than anything.
> > 
> > As has always been the case, I'm here to address any problems that arise 
> > and use
> > my 30 years of experience with GCC development as well as distribution mass
> > rebuilds to make informed decisions about the best course of action for any
> > particular problem.
> 
> Yeah, the s390x failures were anoying. I have several ideas to make
> things more robust that hopefully we can do before next mass rebuild: 
> 
> * move the cache host from a z/vm instance to a kvm one. 
> * We have the kvm ones oversubscribed on cpus, so I'd like to drop all
> of them from 4 cpus to 3. 
> * We might play with the weight on them so koji doesn't run as many jobs
> at a time as it does now.
> * Make sure ci/koji-simple-ci/koschei isn't doing any long running
> builds when the mass rebuild starts. A gcc or libreoffice build can take
> up a builder for a long time. 
> * Run the mass rebuild with --fail-fast so if something fails on some
> other arch, it never even needs to run on s390x. 
> 
> Anyhow, the mass rebuild is over and tagged in. Rawhide compose is
> running and should hopefully finish later today. 
> 
> The second pass took failures from 4162 to 2833, so that helped
> a lot: https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html
Cool.  Thanks for the update.  I'll start scanning through those.  It looks like
some of the cmake things are getting addressed which I'm sure helps too.

Jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: What do to about massive # of FTBFS bugs?

[Jeff Law]

On Mon, 2020-08-03 at 18:39 -0500, Richard Shaw wrote:
> On Mon, Aug 3, 2020 at 6:12 PM Kevin Fenzi  wrote:
> > On Mon, Aug 03, 2020 at 10:28:03PM +0100, Richard W.M. Jones wrote:
> > > On Mon, Aug 03, 2020 at 04:04:57PM -0500, Richard Shaw wrote:
> > > > I'm up to 21 and climbing. Technically two are failure to install...
> > > > 
> > > > I'm confused if I should even fix these right now due to the various 
> > > > issues
> > > > I've seen on the list.
> > > > 
> > > > Is it safe to do builds right now?
> > > 
> > > Everything is blocked on s390 builders not taking new jobs
> > > at the moment ...
> > 
> > Thats me trying to improve things so when they do take jobs they
> > actually complete them correctly. 
> > 
> > You can submit builds just fine right now and they will be picked up as
> > soon as I am done on the builders. 
> 
> Ok, I was wondering if there were still LTO/annobin issues going on. If that 
> was the case I was going to wait a bit.
I would expect to see occasional LTO issues, but nothing pervasive.

The annobin and binutils stuff should all be sorted out. 

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Arch-specific LTO problems

[Jeff Law]

On Mon, 2020-08-03 at 14:06 -0600, Jerry James wrote:
> On Mon, Aug 3, 2020 at 11:33 AM Tom Stellard  wrote:
> > These are all likely caused by the linker running out of memory and
> > getting killed by the OOM killer.
> 
> I see.  In that case, I'll try resubmitting each build once and see if
> the same thing happens.  Thanks, Tom.
If we're blowing up memory on the builder, then we should probably disable LTO 
on
the 32bit platforms.  This is something that was expected, though I didn't trip
over any in my i686 testing (I have a theory for why, but it's not terribly
important).

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: mpich always injects lto flags

[Jeff Law]

On Thu, 2020-08-06 at 15:59 -0600, Christoph Junghans wrote:
> On Wed, Aug 5, 2020 at 7:01 PM Christoph Junghans  wrote:
> > On Wed, Aug 5, 2020 at 2:21 PM Jeff Law  wrote:
> > > On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote:
> > > > On 8/5/20 8:45 PM, Christoph Junghans wrote:
> > > > > Hi,
> > > > > 
> > > > > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > > > > when doing this I hit
> > > > > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > > > > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > > > > which works for the build with openmpi, but gets ignored for the mpich
> > > > > build.
> > > > > 
> > > > > I think the problem is that CMake picks up the lto flags from mpicxx
> > > > > and then puts them in
> > > > > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > > > > 
> > > > > So I think the fix would be to strip these flags from mpicc. Sounds 
> > > > > reasonable?
> > > > > 
> > > > > The flags also contain
> > > > > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > > > > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > > > > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > > > > 
> > > > > Christoph
> > > > > 
> > > > Another related bug is:
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1821728
> > > Note that the BZ complains about -fstack-clash-protection in LLVM which 
> > > has had
> > > various bits landing over the last few months.  So that specific issue 
> > > I'd expect
> > > to resolve itself over time.  The more general issue remains though.
> > https://src.fedoraproject.org/rpms/mpich/pull-request/4
> 
> Can any proven package retrigger
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48824350, the
> tests seem flaky and passed for me here:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48825280
Done.  ppc64le seems to have tested fine this time.  Of course, there's quite a
back-up on s390x, so it'll be a while before it's done and tagged.

jeff


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: What do to about massive # of FTBFS bugs?

[Jeff Law]

On Thu, 2020-08-06 at 17:54 +0200, Fabio Valentini wrote:
> On Thu, Aug 6, 2020 at 4:51 PM Jeff Law  wrote:
> > On Thu, 2020-08-06 at 06:17 -0500, Richard Shaw wrote:
> > > On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini  
> > > wrote:
> > > > I'd say it's pretty safe to submit things to rawhide again. I haven't
> > > > seen any lingering buildroot issues for the past 2-3 days, except for
> > > > some longer wait/build times in koji due to batched ELN build
> > > > submissions (but those are finished now too).
> > > 
> > > Ok, good deal. I've been trying to knock out 2-3 packages a day so I'll 
> > > get to the bottom of the pile in a week or so :)
> > I'm maybe 40% of the way through the failures looking for things that are
> > obviously LTO related and reassigning those to myself.
> > 
> > Based on what I've seen the cmake stuff is still the most common failure.  
> > I've
> > still seen a few s390x infrastructure issues.  Lots of noarch packages that 
> > have
> > failed (haven't looked at those at all since they can't be LTO failures).
> 
> When resubmitting failures caused by intermittent and infra issues, I
> came across a few of those "lto-wrapper failures" on some arches as
> well.
> I can compile a list, if it helps.
Sure that helps.

> 
> I also think LTO can definitely cause issues in noarch builds, if
> mis-compiled archful dependency crashes during the build.
Those kinds of secondary failures do happen.  I've even had tertiary failures
(gcc mis-compiles gas which in turn mis-compiled some X library and your xclock
would render as a mirror image of what it should have -- yes, that's really
happened to me).

Clearly someone is going to need to look at the .noarch things.  But I'm really
focused on first order LTO issues right now.  I'm sure that if there's a second
order issue where LTO is mis-compiling something which in turn causes a .noarch
issue, they'll let the world know...

But the most likely places where an LTO issue is going to show up is in packages
that build code with GCC or LLVM, so that's where I need to focus my time right
now.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: InsightToolkit LTO build failure

[Jeff Law]

On Thu, 2020-08-06 at 20:40 -0600, Orion Poplawski wrote:
> On 8/6/20 9:01 AM, Jeff Law wrote:
> > On Thu, 2020-08-06 at 08:03 -0600, Orion Poplawski wrote:
> > > InsightToolkit fails to build with LTO:
> > > 
> > > /usr/bin/ld.gold: fatal error: lto-wrapper failed
> > > collect2: error: ld returned 1 exit status
> > > gmake[2]: ***
> > > [Modules/Filtering/ImageIntensity/test/CMakeFiles/ITKImageIntensityTestDriver.dir/build.make:1307:
> > > bin/ITKImageIntensityTestDriver] Error 1
> > > 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48777433
> > > 
> > > I'm disabling for now.  Let me know where I should file a bug if needed.
> > No need to file a bug right now.  Once we're past the mass rebuild we'll 
> > review
> > everything that's opted out and see what upstream actions need to be taken.
> > 
> > Note that it appears this package is using the "gold" linker.  That's been
> > deprecated upstream, so you might want to look at transitioning away to 
> > either
> > ld.bfd or lld.
> > 
> > Thanks,
> > jeff
> > 
> 
> Thanks.  However it appears to fails the same way with "ld" (presumably 
> ld.bfd):
I didn't expect it to change, I just wanted to make sure you were aware that
ld.gold is being deprecated and you might want to transition away from it.

Jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

[Jeff Law]

On Tue, 2020-08-04 at 13:16 +0100, Daniel P. Berrangé wrote:
> On Tue, Aug 04, 2020 at 12:02:05PM +0200, Florian Weimer wrote:
> > * Daniel P. Berrangé:
> > 
> > > Taken from https://koji.fedoraproject.org/koji/taskinfo?taskID=48525923
> > 
> > Sorry, what would be more interesting is the linker invocation.  The
> > build log does not show this, only the libtool invocation.  We don't
> > really know what kind of transformations libtool does in this case.
> 
> Upstream libvirt has just yesterday replaced use of autotools with
> meson. I just tried a Fedora rawhide build of our new meson based
> code and it succeeded with LTO.
> 
> Given this, I think I'm fine just disabling LTO in rawhide for the
> current libvirt release, with the expectation we'll re-enable LTO
> in ~1 month time when we import the meson based release of libvirt.
> 
> IOW lets not waste any more time debugging this LTO / LD_PRELOAD
> problem with libvirt.
That works for me.  If you haven't already committed the change, please make a
quite note about the planned move to meson and reenablement of LTO at that point
so I don't dig any further when I review all the opted-out packages.  I'm likely
to forget the decision by the time I'm reviewing the opt-outs.


> 
> > libtool is really not built for LTO, and it really should not be used on
> > GNU systems.  But I understand that this is not uncontroversial.
> There's oooh so many problems with libtool we've hit over the years,
> especially with it re-arranging order of compiler/linker flags, and
> so I'm beyond ecstatic that we've finally thrown it away for libvirt
> in favour of meson.
> 
> There may have been a time & place for libtool and autotools in
> general, but that time has passed
Yea, I find libtool amazingly painful and the primary motivation for it has long
since become a minor issue rather than major one (seriously who cares about
dynamic linking on hpux, sco, irix, etc) anymore.  But killing it I'm sure will
be difficult.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: mame fails to build with LTO enabled

[Jeff Law]

On Fri, 2020-08-07 at 07:19 +0200, Julian Sikorski wrote:
> Hi list,
> 
> mame has failed to build with lto enabled due to violation of C++ one
> definition rule apparently:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48829086
> I don't really know how to fix it. I am going to disable lto for now as,
> according to upstream comment from 2017, mame is likely too big for LTO
> to work anyway [1].
> If anybody would like to help re-enabling the lto, support is
> appreciated. Thanks!

In simplest terms you're not allowed to have a type with global scope with
different definitions.  Look at how BREGS is defined in necpriv.h and v25priv.h.
 THe enum type has the same name (BREGS), but the values in the enum are
different.

Similarly you've got some structures with the same name and external scope, but
with differences in their members (extFloat80M)

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: What do to about massive # of FTBFS bugs?

[Jeff Law]

On Fri, 2020-08-07 at 17:08 +0200, Dominique Martinet wrote:
> Fabio Valentini wrote on Fri, Aug 07, 2020:
> > - waypipe / armv7hl:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48698713
> 
> See the "arm/neon LTO-related FTBS" thread on the list for that one; I
> gave a short recap on the last message on Thursday (Aug 6)
> 
> 
> I'm still unsure if I should disable LTO for now or just patiently wait
> for help at this point, so I'll give Jeff and others another week or two
> first :)
Thanks.  I'm about done with my pass over the failures to find those that are
obviously LTO related and get those assigned to me.

Jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: LTO and the F33 mass rebuild

[Jeff Law]

On Mon, 2020-08-10 at 09:59 +0200, Miro Hrončok wrote:
> On 09. 08. 20 0:02, Jeff Law wrote:
> > For any package which was failing and LTO appeared to be a factor, I've 
> > assigned
> > the package's associated FTBFS BZ to me to address the LTO component.  Some 
> > of
> > those I've already fixed and either closed the BZ or handed it back to the
> > default assignee for non-LTO issues that need to be resolved.
> > 
> > Thus if you have a package on the failing packages list and its still 
> > failing,
> > it's unlikely to be an LTO issue.  I don't mind if you reach out, but start 
> > from
> > the assumption LTO isn't the triggering event.  You can use %define 
> > _lto_cflags
> > %{nil} in your .spec file to disable LTO for testing purposes.
> 
> Thank you Jeff so very much for doing this!
> 
> I've assigned https://bugzilla.redhat.com/show_bug.cgi?id=1865257 to you as 
> well 
> in the spirit of what you've said. The failure is workarounded with %global 
> _lto_cflags %{nil} now.
Thanks.
jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

[Jeff Law]

On Tue, 2020-08-04 at 21:36 +0200, Florian Weimer wrote:
> * Jeff Law:
> 
> > Actually, isn't it "just" 234MB.  Still I'm surprised why that failed.  Do 
> > we
> > have more than one build running at a time on those boxes?
> 
> It's a 32-bit build.  I assume it's not the first large allocation.
> (FWIW, GDB always prints “virtual memory exhausted”, even if the malloc
> failure has a different cause.)
> 
> Does LTO produce more complicated debugging information?  Then maybe
> disabling LTO on armhfp is a workaround.  There's also a way to disable
> debuginfo package generation altogether, something along these lines
> (untested):
It doesn't really make it more complicated, but it does scramble it in fun an
interesting ways.  I'd hazard a guess it changed things in such a way as to
confuse the bits that add the index.

Jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

[Jeff Law]

On Tue, 2020-08-04 at 11:34 -0700, Kevin Fenzi wrote:
> On Tue, Aug 04, 2020 at 07:52:54PM +0200, Miro Hrončok wrote:
> > On 04. 08. 20 18:16, Florian Weimer wrote:
> > > * Miro Hrončok:
> > > 
> > > > Hello, I've got this failure I cannot really understand, it happens on
> > > > armv7hl only (aarch64 and s390x were cancelled):
> > > > 
> > > > Checking for unpackaged file(s): /usr/lib/rpm/check-files
> > > > /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm
> > > > error: Installed (but unpackaged) file(s) found:
> > > > /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
> > > >  Installed (but unpackaged) file(s) found:
> > > > /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
> > > > 
> > > > The gdb-index-9pY4kY files are not created explcitiyl by anything in
> > > > the package.
> > > 
> > > This happens if debuginfo generation fails with a crash:
> > > 
> > > extracting debug info from 
> > > /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped
> > > ../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't 
> > > allocate 234696314 bytes.
> > > A problem internal to GDB has been detected,
> > > further debugging may prove unreliable.
> > > Quit this debugging session? (y or n) [answered Y; input not from 
> > > terminal]
> > > This is a bug, please report it.  For instructions, see:
> > > ;.
> > > /usr/bin/gdb-add-index: line 106: 22699 Aborted (core 
> > > dumped) $GDB --batch -nx -iex 'set auto-load no' -ex "file $file" -ex 
> > > "save gdb-index $dwarf5 $dir"
> > > 
> > > The crash is normally ignored.
> > > 
> > > > Does anybody know what this is?
> > > 
> > > Not enough RAM, apparently.
> > 
> > Thank you Florian, I wonder how can I workaround this issu. Usually this was
> > to lower parallelism during build, but I suppose extracting debug info is
> > not parallelized :/
> 
> I'll note that armv7 buildvm's have 24GB memory. 
> 
> Trying to allocate 234GB doesn't seem very friendly to it working and
> sounds more like a bug somewhere to me.
Actually, isn't it "just" 234MB.  Still I'm surprised why that failed.  Do we
have more than one build running at a time on those boxes?

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Arch-specific LTO problems

[Jeff Law]

On Tue, 2020-08-04 at 08:05 -0700, Tom Stellard wrote:
> On 8/4/20 11:02 AM, Jerry James wrote:
> > On Tue, Aug 4, 2020 at 12:33 AM Jeff Law  wrote:
> > > If we're blowing up memory on the builder, then we should probably 
> > > disable LTO on
> > > the 32bit platforms.  This is something that was expected, though I 
> > > didn't trip
> > > over any in my i686 testing (I have a theory for why, but it's not 
> > > terribly
> > > important).
> > 
> > I will try to come up with a definitive answer today on whether memory
> > exhaustion is or is not the problem.  However, the ppc64le symbol
> > problem with the primecount package appears to be something else
> > entirely.  See https://bugzilla.redhat.com/show_bug.cgi?id=1862181.
> > 
> 
> I think this is also an OOM problem.   I've seen similar error messages
> before when a compiler process gets killed while it is in the middle of
> piping assembly into the assembler.
Agreed.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Help needed to fix a FTBFS (shaderc)

[Jeff Law]

On Sat, 2020-08-08 at 15:51 -0400, Neal Gompa wrote:
> On Sat, Aug 8, 2020 at 3:47 PM Robert-André Mauchin  wrote:
> > On Saturday, 8 August 2020 17:27:54 CEST you wrote:
> > > And so on.
> > > Tons of errors regarding undefined reference to glslang::.
> > > I don't know if this is due to a new Glslang or if something has been
> > > changed wrt the build system, or if system-wide libraries are not 
> > > supported
> > > anymore.
> > > 
> > > Any help for figuring out what happened would be greatly appreciated.
> > > 
> > > Best regards,
> > > 
> > > Robert-André
> > > 
> > 
> > I have the same issue with another FTBFS, soundkonverter:
> > 
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:215: undefined reference to `TagLib::String::String(char
> > const*, TagLib::String::Type)'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:215: undefined reference to `TagLib::String::~String()'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:216: undefined reference to `TagLib::String::String(char
> > const*, TagLib::String::Type)'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:216: undefined reference to `TagLib::String::~String()'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:217: undefined reference to `TagLib::String::String(char
> > const*, TagLib::String::Type)'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:217: undefined reference to `TagLib::String::~String()'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:220: undefined reference to `TagLib::String::String(char
> > const*, TagLib::String::Type)'
> > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function
> > `readXiphTags(TagLib::Ogg::XiphComment*)':
> > /usr/include/c++/10/bits/stl_function.h:386: undefined reference to
> > `TagLib::String::operator<(TagLib::String const&) const'
> > /usr/bin/ld: /usr/include/c++/10/bits/stl_function.h:386: undefined 
> > reference
> > to `TagLib::String::operator<(TagLib::String const&) const'
> > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function
> > `readXiphTags(TagLib::Ogg::XiphComment*)':
> > /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/MetaReplayGain.cpp:
> > 220: undefined reference to `TagLib::String::~String()'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:222: undefined reference to `TagLib::String::String(char
> > const*, TagLib::String::Type)'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:222: undefined reference to `TagLib::String::~String()'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:223: undefined reference to `TagLib::String::String(char
> > const*, TagLib::String::Type)'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:223: undefined reference to `TagLib::String::~String()'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:224: undefined reference to `TagLib::String::String(char
> > const*, TagLib::String::Type)'
> > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/
> > MetaReplayGain.cpp:224: undefined reference to `TagLib::String::~String()'
> > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function
> > `TagLib::Map::~Map() [clone 
> > .lto_priv.0]':
> > /usr/include/c++/10/bits/stl_pair.h:211: undefined reference to
> > `TagLib::StringList::~StringList()'
> > /usr/bin/ld: 
> > /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o:/usr/include/c++/10/
> > bits/stl_pair.h:211: undefined reference to `TagLib::String::~String()'
> > 
> > Is it related to the cmake change? Am I missing something obvious?
> > 
> 
> That looks like failures related to LTO?
No.  I've already check that one.  You'll get the same effective failures 
without
LTO.  More likely it's uninstantiated templates (which is a common source issue,
not a compiler issue)


jeff
> 
> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Help needed to fix a FTBFS (shaderc)

[Jeff Law]

On Sat, 2020-08-08 at 17:27 +0200, Robert-André Mauchin wrote:
> Hello,
> 
> shaderc was FTBFS due to the cmake change, however fixing it does not solve 
> everything. I've got a long list of new errors:
> 
> 
> ===
> [29/29] : && /usr/lib64/ccache/g++ -O2 -flto=auto -ffat-lto-objects -
> fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-
> D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/
> redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/
> redhat-annobin-cc1  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-
> clash-protection -fcf-protection -Wimplicit-fallthrough -O2 -g -DNDEBUG -Wl,-
> z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-
> hardened-ld-rdynamic glslc/CMakeFiles/glslc_exe.dir/src/main.cc.o -o 
> glslc/glslc  glslc/libglslc.a  libshaderc_util/libshaderc_util.a  libshaderc/
> libshaderc.a  libshaderc_util/libshaderc_util.a  -lSPIRV-Tools-opt  -lSPIRV-
> Tools  -lglslang  -lOSDependent  -lOGLCompiler  -lglslang  -lOSDependent  -
> lOGLCompiler  -lSPIRV  -lHLSL  -lpthread && :
> FAILED: glslc/glslc 
> : && /usr/lib64/ccache/g++ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -
> grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-
> D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/
> redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/
> redhat-annobin-cc1  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-
> clash-protection -fcf-protection -Wimplicit-fallthrough -O2 -g -DNDEBUG -Wl,-
> z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-
> hardened-ld-rdynamic glslc/CMakeFiles/glslc_exe.dir/src/main.cc.o -o 
> glslc/glslc  glslc/libglslc.a  libshaderc_util/libshaderc_util.a  libshaderc/
> libshaderc.a  libshaderc_util/libshaderc_util.a  -lSPIRV-Tools-opt  -lSPIRV-
> Tools  -lglslang  -lOSDependent  -lOGLCompiler  -lglslang  -lOSDependent  -
> lOGLCompiler  -lSPIRV  -lHLSL  -lpthread && :
> /usr/bin/ld: /tmp/glslc.KMUNIm.ltrans0.ltrans.o: in function `main':
> /builddir/build/BUILD/shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-
> redhat-linux-gnu/../libshaderc_util/src/compiler.cc:124: undefined reference 
> to `glslang::InitializeProcess()'
> /usr/bin/ld: /tmp/glslc.KMUNIm.ltrans1.ltrans.o: in function 
> `shaderc_util::GlslangInitializer::~GlslangInitializer() [clone .constprop.
> 0]':
> /builddir/build/BUILD/shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-
> redhat-linux-gnu/../libshaderc_util/src/compiler.cc:136: undefined reference 
> to `glslang::FinalizeProcess()'
> /usr/bin/ld: /tmp/glslc.KMUNIm.ltrans1.ltrans.o: in function 
> `shaderc_util::Compiler::Compile(shaderc_util::string_piece const&, 
> EShLanguage, std::__cxx11::basic_string, 
> std::allocator > const&, char const*, std::function (std::ostream*, shaderc_util::string_piece const&)> const&, 
> shaderc_util::CountingIncluder&, shaderc_util::Compiler::OutputType, 
> std::ostream*, unsigned long*, unsigned long*) const [clone .constprop.0]':
> /builddir/build/BUILD/shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-
> redhat-linux-gnu/../libshaderc_util/src/compiler.cc:267: undefined reference 
> to `glslang::TShader::TShader(EShLanguage)'
> /usr/bin/ld: /builddir/build/BUILD/
> shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
> libshaderc_util/src/compiler.cc:271: undefined reference to 
> `glslang::TShader::setStringsWithLengthsAndNames(char const* const*, int 
> const*, char const* const*, int)'
> /usr/bin/ld: /builddir/build/BUILD/
> shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
> libshaderc_util/src/compiler.cc:274: undefined reference to 
> `glslang::TShader::setEntryPoint(char const*)'
> /usr/bin/ld: /builddir/build/BUILD/
> shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
> libshaderc_util/src/compiler.cc:275: undefined reference to 
> `glslang::TShader::setAutoMapBindings(bool)'
> /usr/bin/ld: /builddir/build/BUILD/
> shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
> libshaderc_util/src/compiler.cc:276: undefined reference to 
> `glslang::TShader::setAutoMapLocations(bool)'
> /usr/bin/ld: /builddir/build/BUILD/
> shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
> libshaderc_util/src/compiler.cc:278: undefined reference to 
> `glslang::TShader::setShiftImageBinding(unsigned int)'
> /usr/bin/ld: /builddir/build/BUILD/
> shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
> libshaderc_util/src/compiler.cc:279: undefined reference to 
> `glslang::TShader::setShiftSamplerBinding(unsigned int)'
> /usr/bin/ld: /builddir/build/BUILD/
> shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
> libshaderc_util/src/compiler.cc:280: undefined reference to 
> 

Re: Help needed to fix a FTBFS (shaderc)

[Jeff Law]

On Sat, 2020-08-08 at 22:04 +0200, Robert-André Mauchin wrote:
> On Saturday, 8 August 2020 21:53:57 CEST Jeff Law wrote:
> > More likely it's uninstantiated templates
> 
> I don't know about this, did we change something within Fedora that could 
> trigger this issue while it was working before?
Template instantiation issues are sensitive to inlining heuristics in the
compiler.  Subtle changes in those heuristics can change what gets inlined 
where.

This is a common source level issue.  THe fact that it worked before does not
mean it was correct.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

LTO and the F33 mass rebuild

[Jeff Law]

So I've done two passes over the F33 build failures here:

https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html

For any package which was failing and LTO appeared to be a factor, I've assigned
the package's associated FTBFS BZ to me to address the LTO component.  Some of
those I've already fixed and either closed the BZ or handed it back to the
default assignee for non-LTO issues that need to be resolved.

Thus if you have a package on the failing packages list and its still failing,
it's unlikely to be an LTO issue.  I don't mind if you reach out, but start from
the assumption LTO isn't the triggering event.  You can use %define _lto_cflags
%{nil} in your .spec file to disable LTO for testing purposes.

Having said that, I do expect some LTO issues to still pop up.  For example it's
likely we'll continue to see the cmake issues get resolved in various packages
and I wouldn't be surprised if after fixing a package to work with the new cmake
macros that a small number will trip LTO issues.  I'm obviously here to help 
with
those too.

It's also possible there are packages that are failing and which are not on that
list.  One was passed along to me yesterday (libaio).  Again, happy to help with
analyzing those too.

Anyway, the immediate actions are to find a near term resolution for the LTO
issues which I've assigned to myself in BZ.  There aren't that many and I'm
confident we'll be able to close them out in a reasonable timeframe.

After that I'll be reviewing all the opt-outs to see which we can move forward,
which require upstream GCC bug reports, etc.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: InsightToolkit LTO build failure

[Jeff Law]

On Thu, 2020-08-06 at 08:03 -0600, Orion Poplawski wrote:
> InsightToolkit fails to build with LTO:
> 
> /usr/bin/ld.gold: fatal error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> gmake[2]: *** 
> [Modules/Filtering/ImageIntensity/test/CMakeFiles/ITKImageIntensityTestDriver.dir/build.make:1307:
>  
> bin/ITKImageIntensityTestDriver] Error 1
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48777433
> 
> I'm disabling for now.  Let me know where I should file a bug if needed.
No need to file a bug right now.  Once we're past the mass rebuild we'll review
everything that's opted out and see what upstream actions need to be taken.

Note that it appears this package is using the "gold" linker.  That's been
deprecated upstream, so you might want to look at transitioning away to either
ld.bfd or lld.

Thanks,
jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Lost ELF library auto-provides since mass rebuild

[Jeff Law]

On Thu, 2020-08-06 at 17:04 +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> > This is in relation to this bug
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1862745
> > 
> > The last but one build of libgphoto have auto-provides for the ELF
> > libraries:
> > 
> > libgphoto2 = 2.5.24-2.fc33
> > libgphoto2(x86-64) = 2.5.24-2.fc33
> > libgphoto2.so.6()(64bit)
> > libgphoto2_port.so.12()(64bit)
> > libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
> > libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)
> > 
> > any new build both in the mass rebuild and any scratch builds I try
> > looses some of these auto deps leaving just
> > 
> > libgphoto2 = 2.5.24-3.fc33
> > libgphoto2(x86-64) = 2.5.24-3.fc33
> > libgphoto2.so.6()(64bit)
> > libgphoto2_port.so.12()(64bit)
> > 
> > 
> > Was there any change people are aware of that would explain this and
> > suggest what we need todo to get these deps back in libghoto ?
> 
> I think this isn't the real issue.  As far as I can tell, all the symbol
> versioning information is gone.  The RPM dependencies are correct, but
> the ABI is not. 8-p
> 
> configure.ac has this:
> 
> AC_MSG_CHECKING([for asm .symver support])
> AC_COMPILE_IFELSE([dnl
> AC_LANG_PROGRAM([[]],[[
> int f1() { }
> int f2() { }
> asm(".symver f1, f@VER1");
> asm(".symver f2, f@@VER2");
> int main(int argc, char **argv) { }
> ]])dnl
> ],[
> AC_DEFINE([HAVE_ASM_SYMVERS],1,[Define if there is asm .symver 
> support.])
> VERSIONMAPLDFLAGS="-Wl,--version-script=\$(srcdir)/libgphoto2.ver"
> AC_MSG_RESULT(yes)
> ],[
> VERSIONMAPLDFLAGS=""
> AC_MSG_RESULT(no)
> ])
> AC_SUBST(VERSIONMAPLDFLAGS)
> 
> And build.log shows:
> 
> checking for asm .symver support... no
> 
> The HAVE_ASM_SYMVERS macro is apparently unused, but setting
> VERSIONMAPLDFLAGS looks *very* relevant.
> 
> The cause seems to be this:
> 
> /tmp/ccAbnnro.s: Assembler messages:
> /tmp/ccAbnnro.s: Error: invalid attempt to declare external version name
> as default in symbol `f@@VER2'
> 
> It's LTO-related in the sense that f1 & f2 get different symbols with
> LTO.  This fixes the test:
> 
> int __attribute__ ((externally_visible)) f1() { }
> int __attribute__ ((externally_visible)) f2() { }
> asm(".symver f1, f@VER1");
> asm(".symver f2, f@@VER2");
> int main(int argc, char **argv) { }
> 
> Not sure this was missed by Jeff's config.log differ.  Maybe its
> binutils version was too old?
This package needs to opt-out of LTO.

libgphoto2 passed its control and LTO builds as well as the config.h check.  So
I'm not sure what went wrong here.

jeff

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: InsightToolkit LTO build failure

[Jeff Law]

On Thu, 2020-08-06 at 17:04 +0200, Jakub Jelinek wrote:
> On Thu, Aug 06, 2020 at 09:01:16AM -0600, Jeff Law wrote:
> > No need to file a bug right now.  Once we're past the mass rebuild we'll 
> > review
> > everything that's opted out and see what upstream actions need to be taken.
> > 
> > Note that it appears this package is using the "gold" linker.  That's been
> > deprecated upstream, so you might want to look at transitioning away to 
> > either
> > ld.bfd or lld.
> 
> lld doesn't support linker plugins, does it?  So I don't see how it can be
> an option for GCC LTO.
?!?  Tom would know for sure, of course.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 11:52 +0100, Richard W.M. Jones wrote:
> Here's another one:
> 
>   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
>   libguestfs-tools-c-1.43.1-2.fc33.x86_64
>   readline-8.0-5.fc33.x86_64
>   $ guestfish --version
>   Segmentation fault (core dumped)
> 
>   (gdb) bt
>   #0  0x in  ()
>   #1  0x7f3212b72dad in history_filename
>   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at ../histfile.c:152
>   #2  0x7f3212b75e2d in read_history_range
>   (filename=, from=0, to=-1) at ../histfile.c:280
>   #3  0x5592dd33e646 in main ()
> 
> It also caused a build failure of another package in Koji
> (search the logs for "ext2.img] Segmentation fault (core dumped)"):
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
> 
> I suspect the problem isn't in readline but is in the main package,
> mainly because I tried an older readline and that failed in the same
> way.
> 
> I'm going to disable LTO in libguestfs and rebuild it.
This is almost certainly the linker bug. I analyzed last week.

nm --dynamic guestfish

Would be enough for me to say conclusively.


Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: postgis LTO failure

[Jeff Law]

On Sun, 2020-08-02 at 00:36 +0200, Sandro Mani wrote:
> Hi
> 
> postgis seems another one suffering from LTO related failures.
> 
> LTO (results in test failures): 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48393090
> 
> LTO disabled (tests pass): 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48394173
I've been able to reproduce the testsuite failure.  I'll try to take it from
here.  

Thanks,
jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 18:49 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 10:55:15AM -0600, Jeff Law wrote:
> > On Fri, 2020-07-31 at 14:07 +0200, Florian Weimer wrote:
> > > * Richard W. M. Jones:
> > > 
> > > > Here's another one:
> > > > 
> > > >   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
> > > >   libguestfs-tools-c-1.43.1-2.fc33.x86_64
> > > >   readline-8.0-5.fc33.x86_64
> > > >   $ guestfish --version
> > > >   Segmentation fault (core dumped)
> > > > 
> > > >   (gdb) bt
> > > >   #0  0x in  ()
> > > >   #1  0x7f3212b72dad in history_filename
> > > >   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at 
> > > > ../histfile.c:152
> > > >   #2  0x7f3212b75e2d in read_history_range
> > > >   (filename=, from=0, to=-1) at ../histfile.c:280
> > > >   #3  0x5592dd33e646 in main ()
> > > > 
> > > > It also caused a build failure of another package in Koji
> > > > (search the logs for "ext2.img] Segmentation fault (core dumped)"):
> > > > 
> > > >   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
> > > > 
> > > > I suspect the problem isn't in readline but is in the main package,
> > > > mainly because I tried an older readline and that failed in the same
> > > > way.
> > > 
> > > This looks like the ld bug producing incorrect absolute symbols:
> > > 
> > > $ eu-readelf --symbols=.dynsym usr/bin/guestfish  | grep -w ABS
> > >   790:  54 FUNCGLOBAL DEFAULT  ABS xrealloc
> > >   791:  35 FUNCGLOBAL DEFAULT  ABS xmalloc
> > >   799:    1294 FUNCGLOBAL DEFAULT  ABS 
> > > locale_charset
> > > 
> > > <https://sourceware.org/bugzilla/show_bug.cgi?id=26314>
> > > 
> > > I believe a fix for that is on its way to rawhide.
> > Yup.  binutils with the ld fix is nearly done building (just waiting on 
> > s390x).
> >  I'll have my eye on things today in case there's further fallout.
> > 
> > So Richard, wait for binutils-2.35.8 to hit the buildroots, respin 
> > guestfish and
> > we should be good.
> 
> No problem, will test when it arrives.
Looks like it's in the buildroots now.  Let me know if that doesn't fix the
problem.

jeff
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 aarch64 build failures on copr

[Jeff Law]

On Fri, 2020-07-31 at 11:44 -0300, Augusto Caringi wrote:
> Hi,
> 
> On Thu, Jul 30, 2020 at 12:47 PM Jeremy Linton  wrote:
> > On 7/28/20 4:39 PM, Jeff Law wrote:
> > > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
> > > > On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law  wrote:
> > > > > If this is a new failure (say in the last week), it could be an out
> > > > > of memory
> > > > > scenario.  Try disabling LTO.  The standard way to do that is
> > > > > 
> > > > > %define _lto_cflags %{nil}
> > > > > 
> > > > > In your %build stanza in the spec file.
> > > > > 
> > > > > Heff
> > > > 
> > > > I agree, it's almost certainly OOM because it says "fatal error:
> > > > Killed." I've never seen that happen for any reason other than OOM.
> > > I've seen it happen for a variety of reasons.  Please test with LTO 
> > > disabled and
> > > let me know if that helps.
> > 
> > As a FYI: I had similar problems not long ago building a tensorflow.
> > Reducing the build parallelism in that case helped reduce the memory
> > footprint sufficiently that the build completed.
> 
> I'm facing a similar problem building the bpftrace package...
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48268388
> 
> But for me, it seems gcc is crashing with a simple cmake test program:
> 
> CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:60 (message):
>   The C compiler
> "/usr/bin/cc"
>   is not able to compile a simple test program.
> 
> /builddir/build/BUILD/bpftrace-0.11.0/CMakeFiles/CMakeTmp/testCCompiler.c:1:
> internal compiler error: Segmentation fault
> 
> https://kojipkgs.fedoraproject.org//work/tasks/9180/48269180/build.log
annobin failure.  From the log:

annobin: 
/builddir/build/BUILD/bpftrace-0.11.0/CMakeFiles/CMakeTmp/testCCompiler.c: 
AArch64: The annobin plugin is out of date with respect to gcc

Clearly Nick and Jakub need to be coordinating better to prevent these problems,
they come up far too regularly.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: ar (binutils) segfaulting in Rawhide - known bug?

[Jeff Law]

On Mon, 2020-07-27 at 18:20 +0200, Nikola Forró wrote:
> On Sat, 2020-07-25 at 01:11 -0600, Jeff Law wrote:
> > So at a high level ar makes a call to lrealpath.  That naturally goes 
> > through the
> > PLT.  The PLT stub loads the value out of the GOT and jumps to it.  The 
> > problem
> > is the entry in the GOT is *zero* when it should be pointing to the 
> > resolver.
> > 
> > Now lrealpath is provided by libiberty and a copy is in libbfd.so and the 
> > GOT
> > entry in libbfd.so looked right.  But by the time the program has hit main, 
> > the
> > GOT entry has been reset to zero.  Naturally that's happening inside the 
> > dynamic
> > linker (as expected, confirmed with a watchpoint).  If you've ever had to 
> > debug
> > ld.so, you'll know it's an insanely painful experience, but it proved 
> > fruitful.
> > 
> > The key was finding out that we were not using the libbfd.so linker map to
> > resolve lrealpath, instead we were using the linker map for the main 
> > program (ar
> > in this case).  So natrually it's time to look a bit more closely at the 
> > symbol
> > table for ar.
> > 
> > The main symbol table for ar it doesn't mention lrealpath.  But that's just 
> > a
> > confusing byproduct of having two symbol tables.  What matters to ld.so is 
> > the
> > *dynamic* symbol table.  And ar has lrealpath in its dynamic symbol table.  
> > And
> > here's the kicker, it's an absolute symbol with the value 0:
> > 
> >  A lrealpath
> > 
> > A symbol in the main program takes precedence over a symbol in a DSO.  So 
> > the
> > dynamic linker was actually doing the right thing given the input it was
> > provided.
> > 
> > Now why (*&@#$ does ar have lrealpath as an absolute symbol?  It's got to be
> > related to the fact that when we link ar we pull in another copy of 
> > libiberty.
> >  In fact, ar links against libiberty twice.  Once via -liberty then again 
> > against
> > libiberty.a (and kindof a 3rd time indirectly via libbfd).  BUt even so that
> > shouldn't be creating an absolute symbol.  That's just weird.
> > 
> > This smells like a linker bug to me.  Not surprisingly if I force the 
> > system to
> > use ld.gold, then I don't see the bogus absolute symbol and the resultant ar
> > works just fine.
> > 
> > It's late and I'll dig further over the weekend, but right now this looks 
> > like a
> > linker bug to me.  I may turn off LTO globally or in the various instances 
> > of
> > binutils -- I need to sleep on that.
> 
> I'm seeing the same behavior with man-db, more specifically with accessdb
> linking to libmandb:
> 
> $ nm -D accessdb | grep xmalloc
>  A xmalloc
> 
> Obviously it segfaults, unless I disable LTO.
> 
> Is there a bugzilla for that linker bug?
Note the linker bug should be fixed now.  So you should be able to rebuild 
man-db 
with LTO now.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 17:19 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 05:19:15PM +0100, Richard W.M. Jones wrote:
> > (It's a bit big so I sent this to you privately)
> 
> Ooops, at least that was what I intended to do.
NP.  And yes, this is definitely the linker bug.  THe tell-tale sign is the
absolute symbols (type A in the nm output).

I've got a couple messages from Nick this morning on the issue, but I haven't
reviewed them yet.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > Looks like it's in the buildroots now.  Let me know if that doesn't fix the
> > problem.
> 
> Looks as if "ar" is segfaulting again ...
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> 
> That was built with binutils 2.35-8.fc33
Actually, it's "nm" that's faulting rather than "ar" and it's happening during
debuginfo extraction, so this could be something completely different.

Anyway, I'm looking at it now.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Another possible LTO failure in guestfish (or maybe readline)

[Jeff Law]

On Fri, 2020-07-31 at 14:07 +0200, Florian Weimer wrote:
> * Richard W. M. Jones:
> 
> > Here's another one:
> > 
> >   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
> >   libguestfs-tools-c-1.43.1-2.fc33.x86_64
> >   readline-8.0-5.fc33.x86_64
> >   $ guestfish --version
> >   Segmentation fault (core dumped)
> > 
> >   (gdb) bt
> >   #0  0x in  ()
> >   #1  0x7f3212b72dad in history_filename
> >   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at 
> > ../histfile.c:152
> >   #2  0x7f3212b75e2d in read_history_range
> >   (filename=, from=0, to=-1) at ../histfile.c:280
> >   #3  0x5592dd33e646 in main ()
> > 
> > It also caused a build failure of another package in Koji
> > (search the logs for "ext2.img] Segmentation fault (core dumped)"):
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
> > 
> > I suspect the problem isn't in readline but is in the main package,
> > mainly because I tried an older readline and that failed in the same
> > way.
> 
> This looks like the ld bug producing incorrect absolute symbols:
> 
> $ eu-readelf --symbols=.dynsym usr/bin/guestfish  | grep -w ABS
>   790:  54 FUNCGLOBAL DEFAULT  ABS xrealloc
>   791:  35 FUNCGLOBAL DEFAULT  ABS xmalloc
>   799:    1294 FUNCGLOBAL DEFAULT  ABS locale_charset
> 
> 
> 
> I believe a fix for that is on its way to rawhide.
Yup.  binutils with the ld fix is nearly done building (just waiting on s390x).
 I'll have my eye on things today in case there's further fallout.

So Richard, wait for binutils-2.35.8 to hit the buildroots, respin guestfish and
we should be good.

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Disable LTO for now ?

[Jeff Law]

On Thu, 2020-07-30 at 10:54 +0200, Vitaly Zaitsev via devel wrote:
> On 29.07.2020 15:59, Jeff Law wrote:
> > In general I want to have a very good indicator the issue is LTO related 
> > before I
> > disable.  THe build you referenced doesn't have any good indicators that 
> > LTO is
> > the problem.
> 
> My packages nheko and mtxclient are failed due to LTO. Can you check
> them? Currently built with Clang, but I can try to switch to GCC.
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1558560
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1558793
Umm, those builds look fine -- I don't see any failures in those builds.

I would not generally recommend switching compilers to work around issues of any
kind. 

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org