Release 4.2.0 fails to build if ICU headers are installed in a non-system location #747

Closed
gerdr opened this Issue Mar 23, 2012 · 4 comments

Comments

Projects
None yet
4 participants
Contributor

gerdr commented Mar 23, 2012

Reported by bbkr on #perl6, using Mac OS:

The ICU headers contain a non-prototype function declaration, which breaks the build if the library headers are parsed using Parrot's new warning levels.

By default, gcc ignores warnings from system headers -- ie headers found in standard locations like /usr/include or via -isystem.

Parrot's configuration system needs to be patched so all 3rd-party headers are added via -isystem instead of -I.

Contributor

cotto commented Mar 23, 2012

Is this good to close now that #748 is merged into master?

Contributor

gerdr commented Mar 23, 2012

#748 only fixed bbkr's specific problem - the general one (assuming that 3rd party headers are safe to parse using Parrot's warning levels) still persists.

It normally won't be triggered if you install Parrot's dependencies via package manager, because the headers will end up in a known system location, but MacPorts installed ICU into /opt/local/include, which gcc didn't recognize as containing system headers without being told so explicitly.

Contributor

petdance commented Mar 26, 2012

+1 on making this happen.

Member

rurban commented Nov 23, 2014

Nope. The ICU fix for their broken prototype in 4.2-4.9 is fixed with #867

We don't need -isystem all external headers, and --icuheaders=(path) is enough.
I'm happy to parse external headers with our warnings discipline. It lead to one upstream bug being detected by us, but nothing else.

@rurban rurban closed this Nov 23, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment