Bug 1383552

Summary:	OpenEXR FTBFS against glibc-2.24.90+
Product:	[Fedora] Fedora	Reporter:	Luya Tshimbalanga <luya>
Component:	ilmbase	Assignee:	Rex Dieter <rdieter>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	fweimer, kwizart, rdieter
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-16 15:03:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Luya Tshimbalanga 2016-10-11 02:00:03 UTC

Description of problem:
Koschei reported the recent change from glibc cause failure to build application like Blender with OpenEXR. Here is the build log result from October 3 and onward:
https://kojipkgs.fedoraproject.org/work/tasks/1403/15951403/build.log

https://apps.fedoraproject.org/koschei/package/blender

Version-Release number of selected component (if applicable):
2.2.0

How reproducible:
See Koschei report on blender:
http://koji.fedoraproject.org/koji/buildinfo?buildID=715866

Steps to Reproduce:
1. Attempt to rebuilt Blender on Rawhide
2.
3.

Actual results:
Failure due to the change from glibc

Expected results:
OpenEXC should not generate error

Additional info:

Comment 1 Florian Weimer 2016-10-11 07:11:58 UTC

Out of curiosity, why do you think this is not a glibc bug?

Comment 2 Rex Dieter 2016-10-11 13:11:56 UTC

Some of the errors, include:

/usr/include/OpenEXR/ImathFun.h:135:1: error: 'Imath_2_2::iszero' declared as an 'inline' variable
 iszero (T a, T t)
 ^~~~~~
/usr/include/OpenEXR/ImathFun.h:137:5: error: expected primary-expression before 'return'
     return (IMATH_INTERNAL_NAMESPACE::abs (a) <= t) ? 1 : 0;
     ^~~~~~
/usr/include/OpenEXR/ImathFun.h:137:5: error: expected '}' before 'return'
/usr/include/OpenEXR/ImathFun.h:137:5: error: expected ';' before 'return'
/usr/include/OpenEXR/ImathFun.h: In function 'bool finitef(float)':
/usr/include/OpenEXR/ImathFun.h:249:1: error: ambiguating new declaration of 'bool finitef(float)'
 finitef (float f)
/usr/include/OpenEXR/ImathFun.h: In function 'bool finited(double)':
/usr/include/OpenEXR/ImathFun.h:260:22: error: 'Int64' does not name a type
     union {double d; Int64 i;} u;
                      ^~~~~
/usr/include/OpenEXR/ImathFun.h:263:15: error: 'union finited(double)::<anonymous>' has no member named 'i'
     return (u.i & 0x7ff0000000000000LL) != 0x7ff0000000000000LL;
               ^
/usr/include/OpenEXR/ImathFun.h: At global scope:
/usr/include/OpenEXR/ImathFun.h:267:1: error: expected declaration before '}' token
 IMATH_INTERNAL_NAMESPACE_HEADER_EXIT
 ^

something definitely going bad there, but my guess would be a simple rebuild won't help this (can't hurt to try though)

Comment 3 Rex Dieter 2016-10-11 14:37:47 UTC

Not surprising, rebuild failed with similar errors,

https://koji.fedoraproject.org/koji/taskinfo?taskID=16048818

it would appear that at leaset some glibc math-related functions changed behavior

Comment 4 Rex Dieter 2016-10-11 14:46:58 UTC

adjusting summary

Comment 5 Kevin Kofler 2016-10-12 01:45:54 UTC

I guess this is namespace pollution from glibc macros. As workarounds, you can try:
#undef iszero
or replacing iszero with (iszero) to avoid the function-like macro expansion.

The later errors are probably collateral damage from the parse errors caused by the accidental macro expansion.

Comment 6 Rex Dieter 2016-10-16 14:41:21 UTC

Trying minimalistic (iszero) approach first... (and fyi, the offending header is in ilmbase, a dependency of OpenEXR)

Comment 7 Rex Dieter 2016-10-16 15:03:16 UTC

%changelog
* Sun Oct 16 2016 Rex Dieter <rdieter> - 2.2.0-6
- workaround glibc iszero macro (#1383552)

Comment 8 Florian Weimer 2016-10-21 16:42:36 UTC

glibc-2.24.90-12.fc26 (available in a couple of hours) should no longer need the workaround.