On Thu, Feb 3 2022 at 02:06:19 PM -0600, Michael Catanzaro
wrote:
For now, I'll test dropping down to -g0, but even this will be a
temporary solution ta best. (I don't know if that will work or not
yet. Will try now.)
BTW this seems to have worked. I had to drop the debuginfo packages
too, b
* Michael Catanzaro:
> I have the following i686-only WebKitGTK build failure in rawhide [1]:
>
> ninja: build stopped: stat(lib/libWebCoreGTK.a): Value too large for
> defined data type.
>
> Based on [2], I assume the problem is that either ar or ranlib is not
> built with large file support. Doe
On Tue, Oct 26 2021 at 05:48:14 PM +0100, Ian McInerney via devel
wrote:
None of these feel like cmake-specific flags to me, because -DNDEBUG
is applicable to all build chains
-NDEBUG is different, though, because upstream CMake defines that for
release builds, so upstream projects probably e
Ideally, I think the %cmake macro should only add new cmake-specific flags
that are needed and not add any other ones not defined by the base
distribution to the build. None of these feel like cmake-specific flags to
me, because -DNDEBUG is applicable to all build chains, and the others are
in %opt
On Tue, Oct 26 2021 at 09:06:37 AM -0500, Michael Catanzaro
wrote:
And that means we should not need ExcludeArch after all. Pretty sure
I can make it build now that we understand what went wrong. Happy
ending? Probably, let's see
CC: Björn. I wonder if you expected cmake to propagate thes
On Tue, Oct 26 2021 at 03:40:39 PM +0200, Dan Horák
wrote:
there is a chance on armv7 I think
+ /usr/bin/cmake -S . -B redhat-linux-build
'-DCMAKE_C_FLAGS_RELEASE:STRING=-O2 -g -DNDEBUG'
'-DCMAKE_CXX_FLAGS_RELEASE:STRING=-O2 -g -DNDEBUG'
the "-g" here IMO overrides the -g1 from the earlier fla
On Tue, 26 Oct 2021 08:25:55 -0500
Michael Catanzaro wrote:
> On Tue, Oct 26 2021 at 03:06:18 PM +0200, Kalev Lember
> wrote:
> > I second to Fabio's request. It's not OK to drop webkitgtk secondary
> > architectures without coordination. Please revert this immediately
> > and do a system wid
On Tue, Oct 26, 2021 at 3:26 PM Michael Catanzaro
wrote:
> On Tue, Oct 26 2021 at 03:06:18 PM +0200, Kalev Lember
> wrote:
> > I second to Fabio's request. It's not OK to drop webkitgtk secondary
> > architectures without coordination. Please revert this immediately
> > and do a system wide chan
On Tue, Oct 26 2021 at 03:06:18 PM +0200, Kalev Lember
wrote:
I second to Fabio's request. It's not OK to drop webkitgtk secondary
architectures without coordination. Please revert this immediately
and do a system wide change proposal instead. The net effect of
dropping webkitgtk is that all o
On Tue, Oct 26 2021 at 02:44:53 PM +0200, Fabio Valentini
wrote:
For example, will this mean
Fedora can no longer produce Workstation (or other Spins) images for
arm, (given that e.g. gnome-shell transitively depends on
webkit2gtk3)?
Well for 32-bit ARM yes, for sure.
But aarch64 will be fine
On Tue, Oct 26, 2021 at 2:45 PM Fabio Valentini
wrote:
> On Tue, Oct 26, 2021 at 2:09 PM Michael Catanzaro
> wrote:
> >
> > On Thu, Oct 21 2021 at 06:25:58 PM -0500, Michael Catanzaro
> > wrote:
> > > I'll probably add an ExcludeArch and leave it for 32-bit users to
> > > deal with.
> >
> > OK,
On Tue, Oct 26, 2021 at 2:09 PM Michael Catanzaro wrote:
>
> On Thu, Oct 21 2021 at 06:25:58 PM -0500, Michael Catanzaro
> wrote:
> > I'll probably add an ExcludeArch and leave it for 32-bit users to
> > deal with.
>
> OK, in conclusion, this is what I wound up doing.
>
> Unfortunately, the armv7
On Thu, Oct 21 2021 at 06:25:58 PM -0500, Michael Catanzaro
wrote:
I'll probably add an ExcludeArch and leave it for 32-bit users to
deal with.
OK, in conclusion, this is what I wound up doing.
Unfortunately, the armv7hl build has started failing with the same
problem, even though it was wor
On 10/25/21 2:02 PM, Tom Stellard wrote:
On 10/25/21 2:00 PM, Michael Catanzaro wrote:
On Thu, Oct 21 2021 at 05:15:37 PM -0700, Tom Stellard
wrote:
To do this, you need to add -fuse-ld=lld -Wl,--build-id=sha1 to the linker
flags.
Good news: ld.lld does not run out of memory.
Bad news: b
On 10/25/21 2:00 PM, Michael Catanzaro wrote:
On Thu, Oct 21 2021 at 05:15:37 PM -0700, Tom Stellard
wrote:
To do this, you need to add -fuse-ld=lld -Wl,--build-id=sha1 to the linker
flags.
Good news: ld.lld does not run out of memory.
Bad news: because it crashes. There is a low-quality
On Thu, Oct 21 2021 at 05:15:37 PM -0700, Tom Stellard
wrote:
To do this, you need to add -fuse-ld=lld -Wl,--build-id=sha1 to the
linker flags.
Good news: ld.lld does not run out of memory.
Bad news: because it crashes. There is a low-quality backtrace here:
https://kojipkgs.fedoraproject.o
On Mon, Oct 25 2021 at 08:33:42 AM -0500, Michael Catanzaro
wrote:
I'll try this one as a last-ditch effort, but I don't think it will
work. We'll find out. I expect this will reduce the memory required
*during* linking, but I think the problem here is the *resulting
executable* is just too bi
On Mon, Oct 25 2021 at 01:14:31 PM +0200, Petr Pisar
wrote:
--reduce-memory-overheads
I'll try this one as a last-ditch effort, but I don't think it will
work. We'll find out. I expect this will reduce the memory required
*during* linking, but I think the problem here is the *resultin
V Fri, Oct 22, 2021 at 04:58:35PM -0500, Michael Catanzaro napsal(a):
> I've tried almost everything I can think of: -g0, -Os, disabled LTO. None of
> this worked.
bfd linker has these options:
--no-keep-memory
ld normally optimizes for speed over memory usage by caching the
On Fri, Oct 22, 2021 at 11:24:31PM +0200, Fabio Valentini wrote:
> On Fri, Oct 22, 2021 at 3:49 PM Michael Catanzaro
> wrote:
> >
> > On Thu, Oct 21 2021 at 05:15:37 PM -0700, Tom Stellard
> > wrote:
> > > To do this, you need to add -fuse-ld=lld -Wl,--build-id=sha1 to the
> > > linker flags.
>
On Fri, Oct 22 2021 at 10:34:44 PM -0400, Demi Marie Obenour
wrote:
Does ARMv7 work,
Yes.
and could cross-compiling from x64 work?
Sincerely,
Demi Marie Obenour (she/her/hers)
Presumably it would not fail like this, but we can't do cross builds
for official packages.
Michael
On 10/22/21 5:58 PM, Michael Catanzaro wrote:
> On Fri, Oct 22 2021 at 11:24:31 PM +0200, Fabio Valentini
> wrote:
>> If you do plan to go ahead with this at some point, please consider
>> either announcing it very publicly, or even better, filing a Change
>> proposal for it.
>
> Consider this t
On Fri, Oct 22 2021 at 11:24:31 PM +0200, Fabio Valentini
wrote:
If you do plan to go ahead with this at some point, please consider
either announcing it very publicly, or even better, filing a Change
proposal for it.
Consider this the announcement. ;) Not going to file a change proposal.
I'v
On Fri, Oct 22, 2021 at 3:49 PM Michael Catanzaro wrote:
>
> On Thu, Oct 21 2021 at 05:15:37 PM -0700, Tom Stellard
> wrote:
> > To do this, you need to add -fuse-ld=lld -Wl,--build-id=sha1 to the
> > linker flags.
>
> I suppose I'll give it a try.
>
> ld.bfd just made it even worse:
>
> /usr/bi
On Thu, Oct 21 2021 at 05:15:37 PM -0700, Tom Stellard
wrote:
To do this, you need to add -fuse-ld=lld -Wl,--build-id=sha1 to the
linker flags.
I suppose I'll give it a try.
ld.bfd just made it even worse:
/usr/bin/ld.gold: fatal error: lib/libwebkit2gtk-4.0.so.37.55.4: mmap:
failed to all
On 10/21/21 4:55 PM, Michael Catanzaro wrote:
On Fri, Oct 22 2021 at 12:38:20 AM +0100, Tom Hughes wrote:
Is there a reason for using gold? Maybe the default bfd linker would
manage to use less memory?
I will try with ld.bfd to see if that does any better. I don't remember for
sure why WebKi
On Fri, Oct 22 2021 at 12:38:20 AM +0100, Tom Hughes
wrote:
Is there a reason for using gold? Maybe the default bfd linker would
manage to use less memory?
I will try with ld.bfd to see if that does any better. I don't remember
for sure why WebKit prefers ld.gold, it's either to reduce RAM us
On 22/10/2021 00:25, Michael Catanzaro wrote:
Hi, I'm having trouble building webkit2gtk3-2.34.1 for i686 in rawhide.
An example build failure [1] looks like:
/usr/bin/ld.gold: fatal error: lib/libwebkit2gtk-4.0.so.37.55.4: mmap:
failed to allocate 2108254132 bytes for output file: Cannot all
28 matches
Mail list logo
