Mac OS X: -Werror=strict-prototypes causes compilation of dyncall_thunk* to fail #38

Closed
hds opened this Issue May 15, 2012 · 7 comments

Comments

Projects
None yet
2 participants
@hds

hds commented May 15, 2012

The switch -Werror=strict-prototypes causes compilation of dyncall to fail. Here's the end of the compile log (a larger extract can be found at http://pastebin.com/NBnaQ24s):

In file included from dyncall_thunk.c:27:
dyncall_thunk.h:59: error: function declaration isn't a prototype
In file included from dyncall_thunk.h:64,
from dyncall_thunk.c:27:
dyncall_thunk_x64.h:32: error: function declaration isn't a prototype
In file included from dyncall_thunk.c:33:
dyncall_thunk_x64.c:28: error: function declaration isn't a prototype
make[2]: *** [dyncall_thunk.o] Error 1
make[1]: *** [dyncallback] Error 2
make: *** [3rdparty/dyncall/dyncall/libdyncall_s.a] Error 2

I'm compiling with the tools that come with Xcode 4.3.2 (4E2002):
i686-apple-darwin11-llvm-gcc-4.2
i686-apple-darwin11-llvm-g++-4.2

The flag itself is imported from parrot (or at least I could find it nowhere in the nqp source, but it does exist in the parrot source). To test I tried compiling the latest version of the dyncall library (0.7) on the same machine I I get the same behaviour. If I add the flag (which doesn't exist in their Makefile) then the compile fails with exactly the same error, otherwise it compiles with no problems.

@gerdr

This comment has been minimized.

Show comment Hide comment
@gerdr

gerdr May 16, 2012

Contributor

I thought I fixed that problem with 99f34ab - it seems gcc 4.2 doesn't think that -w should take precedence...

Could you check if this helps:

diff --git a/3rdparty/dyncall/GNUmakefile b/3rdparty/dyncall/GNUmakefile
index 89a6e76..24a5f9c 100644
--- a/3rdparty/dyncall/GNUmakefile
+++ b/3rdparty/dyncall/GNUmakefile
@@ -20,7 +20,7 @@
 #

 # FIXME: workaround for Parrot issue #735
-CFLAGS   := $(CFLAGS) -w
+CFLAGS   := $(CFLAGS) -w -Wno-strict-prototypes

 TOP       = .
 GMAKE_TOP ?= $(TOP)/buildsys/gmake
Contributor

gerdr commented May 16, 2012

I thought I fixed that problem with 99f34ab - it seems gcc 4.2 doesn't think that -w should take precedence...

Could you check if this helps:

diff --git a/3rdparty/dyncall/GNUmakefile b/3rdparty/dyncall/GNUmakefile
index 89a6e76..24a5f9c 100644
--- a/3rdparty/dyncall/GNUmakefile
+++ b/3rdparty/dyncall/GNUmakefile
@@ -20,7 +20,7 @@
 #

 # FIXME: workaround for Parrot issue #735
-CFLAGS   := $(CFLAGS) -w
+CFLAGS   := $(CFLAGS) -w -Wno-strict-prototypes

 TOP       = .
 GMAKE_TOP ?= $(TOP)/buildsys/gmake
@hds

This comment has been minimized.

Show comment Hide comment
@hds

hds May 16, 2012

I've just tried again, but now I'm getting a parrot 4.3.0 / 4.4.0 related error:

Incompatible versions of `core_ops' oplib, possibly due to loading bytecode generated by an old version of Parrot. Found 4.4.0 but loaded 4.3.0

I'm guessing this is unrelated though, should I give it a shot from a slightly older revision of nqp?

hds commented May 16, 2012

I've just tried again, but now I'm getting a parrot 4.3.0 / 4.4.0 related error:

Incompatible versions of `core_ops' oplib, possibly due to loading bytecode generated by an old version of Parrot. Found 4.4.0 but loaded 4.3.0

I'm guessing this is unrelated though, should I give it a shot from a slightly older revision of nqp?

@gerdr

This comment has been minimized.

Show comment Hide comment
@gerdr

gerdr May 16, 2012

Contributor

Yes, that should be unrelated. You can either downgrade your NQP to 5308279 or earlier or fix your parrot installation.

Contributor

gerdr commented May 16, 2012

Yes, that should be unrelated. You can either downgrade your NQP to 5308279 or earlier or fix your parrot installation.

@hds

This comment has been minimized.

Show comment Hide comment
@hds

hds May 16, 2012

Yep, that's fixed the problems. Thanks!

hds commented May 16, 2012

Yep, that's fixed the problems. Thanks!

@gerdr gerdr closed this in 45ed99f May 16, 2012

@gerdr

This comment has been minimized.

Show comment Hide comment
@gerdr

gerdr May 16, 2012

Contributor

@hds should be fixed in master now

The patch I just pushed is slightly different from the one I posted here, so please holler if it doesn't work as advertised ;)

Contributor

gerdr commented May 16, 2012

@hds should be fixed in master now

The patch I just pushed is slightly different from the one I posted here, so please holler if it doesn't work as advertised ;)

@hds

This comment has been minimized.

Show comment Hide comment
@hds

hds May 16, 2012

Will do, thanks again. (-:

hds commented May 16, 2012

Will do, thanks again. (-:

@hds

This comment has been minimized.

Show comment Hide comment
@hds

hds May 17, 2012

Yes, this is now working fine for me from HEAD.

hds commented May 17, 2012

Yes, this is now working fine for me from HEAD.

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