On 6/26/19 3:25 AM, Philip Kovacs via devel wrote:
I am finding that one of my c++ packages has compilation units that
generate very large assembly (.s)
files -- so large that any attempt to build them in memory (e.g. with
-pipe) causes memory exhaustion.
The only way I have found to reliably
> On Wednesday, June 26, 2019, 02:42:29 AM EDT, Dan Horák
wrote:>
> what package is it?
fastbit. This evening I retired it in master since no upstream updates have
been issued since 02/2016.
https://src.fedoraproject.org/rpms/fastbit
The build problems are completely recent, nothing
On Wed, 26 Jun 2019 05:33:24 + (UTC)
Philip Kovacs via devel wrote:
> > On Wednesday, June 26, 2019, 01:05:13 AM EDT, John Reiser
> > wrote:
>
> > Please quantify: What is the byte size of the .s file?
>
> > First hint: give the virtual machine enough resources!
> > Either RAM, or
> On Wednesday, June 26, 2019, 01:05:13 AM EDT, John Reiser
> wrote:
> Please quantify: What is the byte size of the .s file?
> First hint: give the virtual machine enough resources!
> Either RAM, or "swap" (paging) space.
The .s got up to about 375M before that particular g++ compile
On 6/26/19 00:25 UTC, Philip Kovacs via devel wrote:
I am finding that one of my c++ packages has compilation units that generate
very large assembly (.s)
files -- so large that any attempt to build them in memory (e.g. with -pipe)
causes memory exhaustion.
The only way I have found to
On Tue, Jun 25, 2019 at 7:15 PM Philip Kovacs via devel
wrote:
> I am finding that one of my c++ packages has compilation units that generate
> very large assembly (.s)
> files -- so large that any attempt to build them in memory (e.g. with -pipe)
> causes memory exhaustion.
> The only way I
I am finding that one of my c++ packages has compilation units that generate
very large assembly (.s)files -- so large that any attempt to build them in
memory (e.g. with -pipe) causes memory exhaustion.The only way I have found to
reliably get the build to run to completion is by using
