adding -Werror=strict-prototypes to CFLAGS breaks nqp build on some platforms #735

Open
moritz opened this Issue Mar 16, 2012 · 4 comments

Projects

None yet

5 participants

@moritz
Contributor
moritz commented Mar 16, 2012

As you can see in https://gist.github.com/2050618 the change to add -Werror=strict-prototypes to CFLAGS breaks building dyncall, which is bundled in nqp.

In the long run we probably shouldn't pass all of parrots CFLAGs to third party code to compile, but it's not economical to write another configure system for NQP. Maybe we could split CFLAGS into two options, one that contains those switches that should be used by downstream projects like NQP (those concerning binary compatibility, for example), and a second one that is private to parrot.

Owner
leto commented Mar 16, 2012

Yeah, Parrot passing all of the flags we expect to compile with down to all 3rd party/vendor code is probably not a feature.

+1 to @moritz's suggestion of splitting CFLAGS into internal/vendor

Contributor
gerdr commented Mar 16, 2012

The reason why the build fails only on some platforms is probably related to the version of GNU make: according to the manual, make used to export variables by default, but no longer does so.

In particular, the recursive call to make which builds dyncall inherits its CFLAGS from Parrot only on older versions of make, whereas on newer ones, the value from the environment is used.

Contributor

I'm glad to hear the general consensus be for "hide our more restrictive CFLAGS from others" rather than "dumb down our CFLAGS"

Member
rurban commented Nov 23, 2014

How did we fix this?
We have a makefile expander which deals with those ccwarn or optimize overrides, which can easily be used by all the languages.

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