Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
gerdr opened this Issue · 4 comments

4 participants

Gerhard R. cotto Andy Lester Reini Urban
Gerhard R.

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.

cotto
Owner

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

Gerhard R.

#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.

Andy Lester

+1 on making this happen.

Reini Urban
Collaborator

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.

Reini Urban rurban closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.