Leopard: webkit-gtk: fatal error: 'Block.h' file not found

[ryandesign (Ryan Carsten Schmidt)]

On Leopard i386 I got this error building webkit-gtk @2.0.0_2:

In file included from Source/WTF/wtf/MainThread.cpp:34:
./Source/WTF/wtf/Functional.h:36:10: fatal error: 'Block.h' file not found
#include <Block.h>
         ^
1 error generated.

[cooljeanius (Eric Gallager)]

Mountain Lion's Block.h

[cooljeanius (Eric Gallager)]

Pretty sure Objective-C Blocks were introduced in Snow Leopard...

[gnw3]

In 10.6.8 with Xcode-3.2.6 there is:

/Developer/SDKs/MacOSX10.6.sdk/usr/include/Block.h

Peeking inside Mountain Lion's Block.h shows things like:

BLOCK_EXPORT void *_Block_copy(const void *aBlock)
32	    __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_2);

so Snow Leopard should support this.

[larryv (Lawrence Velázquez)]

Uhm yes, Apple first shipped an ABI implementation for blocks with 10.6. Ryan is using 10.5.

(Pet peeve: Blocks are not an Objective-C thing. They are a C extension.)

[cooljeanius (Eric Gallager)]

Replying to larryv@…:

Uhm yes, Apple first shipped an ABI implementation for blocks with 10.6. Ryan is using 10.5.

(Pet peeve: Blocks are not an Objective-C thing. They are a C extension.)

Right, that's what I meant, sorry

[jeremyhu (Jeremy Huddleston Sequoia)]

That should be inside cpp guards for blocks support:

#ifdef __BLOCKS__
...
#endif

[jeremyhu (Jeremy Huddleston Sequoia)]

Ah, the problem is that __BLOCKS__ is defined because the *compiler* supports it, but that doesn't mean the target does...

[jeremyhu (Jeremy Huddleston Sequoia)]

Please try:

Index: Portfile
===================================================================
--- Portfile	(revision 110483)
+++ Portfile	(working copy)
@@ -217,6 +217,9 @@
         depends_build-append      port:python27
         # https://trac.macports.org/ticket/35793
         configure.python          ${prefix}/bin/python2.7
+
+        # https://trac.macports.org/ticket/38682
+        configure.optflags-append -fno-blocks
     }
 
     if {[string match "*10.5*" ${configure.sdkroot}] ||

[ryandesign (Ryan Carsten Schmidt)]

The patch doesn't have the desired effect. The default for cflags, cxxflags, etc. is optflags, but that default is evaluated the first time cflags, cxxflags, etc. are accessed. cxxflags are accessed earlier than this in the portfile (to append -Wno-c++11-extensions when the compiler is clang), therefore changing optflags here has no effect for cxxflags, so the error message is the same.

After revising the patch to order those things correctly, it fails later on with cc1: error: unrecognized command line option "-fno-blocks". CC was /usr/bin/gcc-4.2, despite the fact that the port intends to blacklist that compiler. Again the problem is that variables were accessed in the wrong order: configure.cc was accessed to add CC to the build environment, then later compilers were blacklisted.

Switching the order so that compilers are blacklisted before configure.cc is accessed works. The build succeeds on Leopard i386. The complete fix is attached.

[ryandesign (Ryan Carsten Schmidt)]

working patch

[jeremyhu (Jeremy Huddleston Sequoia)]

r110511