Re: Chromium failing on aarch64 in rawhide

On Fri, 2020-07-31 at 13:26 -0400, Tom Callaway wrote: > This one is odd. Chromium is failing on aarch64 in rawhide, on a bit of > ffmpeg code that has not changed in _years_. > > [clear_key_cdm:13/13] g++ -shared -Wl,--fatal-warnings -fPIC > -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,def

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

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: >

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

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 &

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

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 agai

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

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 agai

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

On Fri, 2020-07-31 at 20:51 +0100, Richard W.M. Jones wrote: > On Fri, Jul 31, 2020 at 01:37:25PM -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 l

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

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 agai

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

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 agai

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

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 l

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

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 > di

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

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

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

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 thi

Re: postgis LTO failure

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/

Re: postgis LTO failure

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/

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

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é: > > > > >

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

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

Re: Arch-specific LTO problems

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 > th

Re: Arch-specific LTO problems

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 32b

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

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 (aarc

Re: mpich always injects lto flags

On Wed, 2020-08-05 at 12:45 -0600, 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

Re: mpich always injects lto flags

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

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

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 koj

Re: InsightToolkit LTO build failure

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.di

Re: Lost ELF library auto-provides since mass rebuild

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.2

Re: InsightToolkit LTO build failure

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 act

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

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

Re: mpich always injects lto flags

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:4

Re: mame fails to build with LTO enabled

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

Re: InsightToolkit LTO build failure

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-wrap

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

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 th

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

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 in

Re: Help needed to fix a FTBFS (shaderc)

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 Gls

Re: Help needed to fix a FTBFS (shaderc)

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

Re: Help needed to fix a FTBFS (shaderc)

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/2

LTO and the F33 mass rebuild

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 al

Re: LTO and the F33 mass rebuild

On Sun, 2020-08-09 at 12:02 +0200, Fabio Valentini wrote: > On Sun, Aug 9, 2020 at 12:03 AM Jeff Law wrote: > > So I've done two passes over the F33 build failures here: > > > > https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html > > Hi Jeff

Re: LTO and the F33 mass rebuild

On Sun, 2020-08-09 at 12:02 +0200, Fabio Valentini wrote: > On Sun, Aug 9, 2020 at 12:03 AM Jeff Law wrote: > > So I've done two passes over the F33 build failures here: > > > > https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html > > Hi Jeff

Re: LTO and the F33 mass rebuild

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

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

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-b

Re: LTO and the F33 mass rebuild

On Sun, 2020-08-09 at 12:02 +0200, Fabio Valentini wrote: > On Sun, Aug 9, 2020 at 12:03 AM Jeff Law wrote: > > So I've done two passes over the F33 build failures here: > > > > https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html > > Hi Jeff

Re: LTO and the F33 mass rebuild

On Tue, 2020-08-11 at 06:34 -0500, Richard Shaw wrote: > Looks like js8call is failing due to LTO... > > /usr/bin/ld: /tmp/js8call.Y0yEHy.ltrans36.ltrans.o: in function > `EqualizationToolsDialog::~EqualizationToolsDialog()': > /builddir/build/BUILD/js8call-2.2.0/EqualizationToolsDialog.hpp:12: u

Re: Please untag dotnet3.1-3.1.106-1.fc33

On Thu, 2020-08-13 at 10:21 -0400, Omair Majid wrote: > Hi, > > One of the recent builds produced for "dotnet3.1" for rawhide is broken > on aarch64. It built successfully in koji, but produced aarch64 binaries > that segfault on startup. A new build of dotnet3.1 requires a working > older build.

Re: Please untag dotnet3.1-3.1.106-1.fc33

On Thu, 2020-08-13 at 11:13 -0400, Omair Majid wrote: > Jeff Law writes: > > > I can't help with the untagging, but I'm here if there's anything > > going wrong with the system tools that is ultimately affecting dotnet. > > Thanks. > > Just fo

Re: Pinta failed to build on f33/armv7hl

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 hel

LTO and F33

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 potent

Re: LTO and F33

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 w

Re: chromium/ffmpeg fails on aarch64 in F33+

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

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

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. >

Re: LTO and F33

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

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

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

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

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 > > An

Re: The case of LTO when produced enlarged binaries

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 b

Re: The case of LTO when produced enlarged binaries

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:

Re: FYI Fedora 34 OCaml 4.11.1 rebuild

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=1870

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

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 Bi

Re: LTO and F33

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

Re: LTO and F33

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

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

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

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

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 fo

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

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

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

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 c

Re: LTO and F33

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

Re: LTO and F33

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: h

Re: LTO and F33

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: h

Re: LTO and F33

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

Re: LTO and F33

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

Re: LTO and F33

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

Re: Fedora 33 blocker status

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

Re: Fedora 33 blocker status

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

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

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

Re: readelf seems broken in F33

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.

Re: final link failed: memory exhausted on armv7l

On 10/13/2021 10:37 AM, Michael Catanzaro wrote: On Wed, Oct 13 2021 at 06:06:50 PM +0200, Björn 'besser82' Esser wrote: What you describe as lto requires a lot of memory is caused by building lto along with non-lto in the same object file requires significantly more memory.  For that reason

Re: final link failed: memory exhausted on armv7l

On 10/13/2021 10:06 AM, Björn 'besser82' Esser wrote: Building with lto disabled is a bad idea, as Fedora intentionally enabled lto by default. Yes, but there is nothing inherently wrong with not using LTO.  Many packages opt-out for various reasons. What you describe as lto requires a lot

Re: final link failed: memory exhausted on armv7l

On 10/13/2021 8:51 AM, Björn 'besser82' Esser wrote: Am Mittwoch, dem 13.10.2021 um 15:44 +0200 schrieb Iñaki Ucar: Hi, RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide [3, 4] with this message (memory exhausted). The same build on the same machine (CPU and RAM) succeeds on

Re: LTO objects after build: Rebuilding vs erroring out

On 11/15/2021 6:06 AM, Florian Weimer wrote: In the future, we might want to switch GCC not to generate both object code and LTO representation during the build process. For most packages, dual generation is not necessary because no relocatable object files for static linking are included in t

Re: readelf seems broken in F33

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 UN

Re: ELF section/file compression

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

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

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

Re: glibc troubles in rawhide?

On 10/20/20 4:41 PM, Jerry James wrote: > On Tue, Oct 20, 2020 at 4:38 PM Fabio Valentini wrote: >> Looks like the most recent glibc update in rawhide broke some stuff, >> including running dnf: > That looks like the same problem I wrote about this morning: > > https://lists.fedoraproject.org/arc

Re: glibc troubles in rawhide?

On 10/20/20 4:47 PM, Neal Gompa wrote: > On Tue, Oct 20, 2020 at 6:44 PM Jeff Law wrote: >> >> On 10/20/20 4:41 PM, Jerry James wrote: >>> On Tue, Oct 20, 2020 at 4:38 PM Fabio Valentini >>> wrote: >>>> Looks like the most recent glibc update in raw

Re: glibc troubles in rawhide?

On 10/20/20 5:14 PM, Adam Williamson wrote: > On Tue, 2020-10-20 at 18:47 -0400, Neal Gompa wrote: >> Can >> we use our gating system to kick back builds that are obviously broken >> that even the package manager stops working? > Theoretically, yes, this is possible. We could add this and any othe

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

On 10/22/20 7:02 AM, Kalev Lember wrote: > On Thu, Oct 22, 2020 at 2:54 PM Neal Gompa > wrote: > > On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova > mailto:al...@bookwar.info>> wrote: > > > > Hi, all, > > > > this is the informational message

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

On 10/22/20 6:53 AM, Neal Gompa wrote: > On Thu, Oct 22, 2020 at 8:27 AM 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 F

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

On 10/22/20 7:00 AM, Daniel P. Berrangé wrote: > On Thu, Oct 22, 2020 at 02:27:13PM +0200, 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 GC

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

On 10/22/20 8:09 AM, Daniel P. Berrangé wrote: > On Thu, Oct 22, 2020 at 04:03:33PM +0200, Aleksandra Fedorova wrote: >> Hi, Daniel, >> >> On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé >> wrote: >>> On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote: Hi, all,

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

On 10/22/20 8:27 AM, Petr Pisar wrote: > On Thu, Oct 22, 2020 at 08:10:02AM -0600, Jeff Law wrote: >> I do think we need to make it easier for a Fedora package maintainer to >> get the gcc-11 bits so that if there's a need to debug a bad interaction >> between gcc

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

On 10/22/20 9:28 AM, Petr Pisar wrote: > On Thu, Oct 22, 2020 at 09:20:28AM -0600, Jeff Law wrote: >> On 10/22/20 8:27 AM, Petr Pisar wrote: >>> On Thu, Oct 22, 2020 at 08:10:02AM -0600, Jeff Law wrote: >>>> I do think we need to make it easier for a Fedora package

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

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

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

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 > s

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

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' m

Re: ld segfaults on rawhide

On 10/31/20 9:13 AM, Christoph Junghans wrote: > Hi, > > I am getting the following error on all archs on rawhide: > collect2: fatal error: ld terminated with signal 11 [Segmentation > fault], core dumped > in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411 > > any ideas? Given it's

Re: ld segfaults on rawhide

On 11/3/20 9:56 AM, Kevin Fenzi wrote: > On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote: >> On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes wrote: >>> On Sat, Oct 31, 2020 at 10:32 AM Jeff Law wrote: >>>> >>>> On 10/31/20 9:13 AM, Christo

Re: Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)

On 11/4/20 2:06 PM, Tom Stellard wrote: > On 11/4/20 3:57 PM, Jakub Jelinek wrote: >> On Wed, Nov 04, 2020 at 03:51:40PM -0500, Neal Gompa wrote: Well, gcc really should have either weak or strong dependency on make too given that -flto is now used everywhere. >>> >>> The goal of th

Re: HEADSUP: libsepol and libsemanage soname bump

On 11/5/20 7:59 AM, Petr Lautrbach wrote: > On Wed, Nov 04, 2020 at 09:47:50AM +0100, Petr Lautrbach wrote: >> Hi, >> >> in order to prevent backward compatibility libsepol and libsemanage used had >> few >> symbols defined twice and used symbol versioning for them. But when LTO was >> enabled th

Re: Rawhide build failure on strange archs

On 11/7/20 1:38 PM, Orion Poplawski wrote: > On 11/7/20 1:26 PM, Steve Dickson wrote: >> Hello, >> >> I'm getting a build failure on the armv7hl arch >> and the i686 arch, which do not make much sense. >> >> The build is [1] and only those arche are  complaining about an >> sprintf() statement. >>

Re: qemu & LTO

On 11/5/20 8:24 AM, Richard W.M. Jones wrote: > We discovered a few days ago that LTO broke qemu on aarch64. > > The original bug reported was: > > https://bugzilla.redhat.com/show_bug.cgi?id=1893892 > > But actually looking at the build.log[1] we see another assertion > failure in the test suit

Re: gcc-11 rawhide mock config?

On 11/25/20 5:41 AM, Gabriel L. Somlo wrote: > Hi, > > Someone dropped a gcc-11 specific patch into a package I > (co-)maintain: > > https://src.fedoraproject.org/rpms/yosys/c/ff37aa8a48b430546f4831ece89896cccfe7b1a1?branch=master > > which really rather belongs upstream. I'd like to test it befo

Re: LTO running out of memory on ARMv7 builders

On 12/1/20 12:05 PM, Richard W.M. Jones wrote: > This Rawhide build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=56536942 > seems to have failed because of LTO running out of memory on armv7. > The error is: > > lto1: out of memory allocating 104 bytes after a total of 2966994944 byte

Re: Nothing provides libgnat-10.so()(64bit)

On 12/7/20 11:07 AM, Jakub Jelinek wrote: > On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote: >> Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit): > I'm not a provenpackager, so I'm afraid I can't do that myself. > Perhaps the maintainers can just rebuild the

Re: Nothing provides libgnat-10.so()(64bit)

On 12/7/20 1:48 PM, Pavel Zhukov wrote: > Hi Jeff. > Thank you for rebuilding xmlada. I'll continue from there as I want to > use this bootstrap to update packages to newest upstream version > anyway . ACK.  That'll definitely help.  I'll keep my gprbuild bits here (they aren't complete/working a

<    1   2   3   >