Bug 1025143 - Internal error: .size expression not evaluate to a constent
Internal error: .size expression not evaluate to a constent
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
x86_64 Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-31 01:57 EDT by Lameire Alexis
Modified: 2013-11-01 08:54 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-01 08:54:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lameire Alexis 2013-10-31 01:57:26 EDT
Description of problem:
I try to update my package minion, but build fail with :

{standard input}: Assembler messages:
{standard input}:1384863: Warning: end of file not at end of a line; newline inserted
{standard input}: Error: .size expression for _ZN22ReifiedEqualConstraintI20BoundVarRef_internalIiE10VarRefTypeI26SparseBoundVarRef_internalIiEE15QuickVarRefTypeI19GetBoolVarContainer19BoolVarRef_internalELb1EE8get_varsEv does not evaluate to a constant

This bug look like to be architecture specific, I don't have it on i686

Version-Release number of selected component (if applicable):
I try to compile into rawhide and f20


How reproducible:
rebuild last version of minon package into koji infrastructure

Additional info:
https://koji.fedoraproject.org/koji/taskinfo?taskID=6117479 (build for rawhide)
https://koji.fedoraproject.org/koji/taskinfo?taskID=6117596 (build for f20)
Comment 1 Jakub Jelinek 2013-10-31 03:53:20 EDT
You are misreading the problem.  The assembler messages are clearly just because you are using -pipe and the compiler has been killed by the kernel:
c++: internal compiler error: Killed (program cc1plus)
so it stopped writing more assembler into the pipe.
Now, the question is how much memory did cc1plus need to compile that, how many compilers and other potentially memory hungry processes were running at the same time and if the memory requirements are corresponding to the complexity of the source you are compiling.  If you attach preprocessed source of the file on which cc1plus eats most memory, I can have a look at where the memory is spent on and if it is a g++ bug or not.
Comment 2 Lameire Alexis 2013-11-01 08:54:42 EDT
Your information is exact. The koji buildsystem limit ressources on build task. When I disable parallel build, this solve the bug. 

Thenks for help.

Note You need to log in before you can comment on or make changes to this bug.