I hit some problems compiling a C++ extension in a non-threaded
environment, because of some missing extern "C" declarations. Looks like
this was previously fixed for threaded mode only. Please would someone
with karma apply the following patch?
Index: zend_globals_macros.h
RCS file: /repository/ZendEngine2/zend_globals_macros.h,v
retrieving revision 1.22.2.1.2.2
diff -u -r1.22.2.1.2.2 zend_globals_macros.h
--- zend_globals_macros.h 18 Jul 2006 09:06:33 -0000 1.22.2.1.2.2
+++ zend_globals_macros.h 23 Jan 2007 14:57:45 -0000
@@ -34,8 +34,10 @@
END_EXTERN_C()
#else
define CG(v) (compiler_globals.v)
+BEGIN_EXTERN_C()
extern ZEND_API struct _zend_compiler_globals compiler_globals;
int zendparse(void);
+END_EXTERN_C()
#endif
@@ -44,7 +46,9 @@
define EG(v) TSRMG(executor_globals_id, zend_executor_globals *, v)
#else
define EG(v) (executor_globals.v)
+BEGIN_EXTERN_C()
extern ZEND_API zend_executor_globals executor_globals;
+END_EXTERN_C()
#endif
/* Language Scanner */
I hit some problems compiling a C++ extension in a non-threaded
environment, because of some missing extern "C" declarations. Looks like
this was previously fixed for threaded mode only. Please would someone
with karma apply the following patch?
What about ini_scanner_globals & language_scanner_globals?
Don't they require the same declaration?
Also, how to reproduce it?
I compile C++ extensions quite often and do not see any problems.
Index: zend_globals_macros.h
RCS file: /repository/ZendEngine2/zend_globals_macros.h,v
retrieving revision 1.22.2.1.2.2
diff -u -r1.22.2.1.2.2 zend_globals_macros.h
--- zend_globals_macros.h 18 Jul 2006 09:06:33 -0000 1.22.2.1.2.2
+++ zend_globals_macros.h 23 Jan 2007 14:57:45 -0000
@@ -34,8 +34,10 @@
END_EXTERN_C()
#elsedefine CG(v) (compiler_globals.v)
+BEGIN_EXTERN_C()
extern ZEND_API struct _zend_compiler_globals compiler_globals;
int zendparse(void);
+END_EXTERN_C()
#endif@@ -44,7 +46,9 @@
define EG(v) TSRMG(executor_globals_id, zend_executor_globals *, v)
#else
define EG(v) (executor_globals.v)
+BEGIN_EXTERN_C()
extern ZEND_API zend_executor_globals executor_globals;
+END_EXTERN_C()
#endif/* Language Scanner */
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
I hit some problems compiling a C++ extension in a non-threaded
environment, because of some missing extern "C" declarations. Looks
like this was previously fixed for threaded mode only. Please would
someone with karma apply the following patch?What about ini_scanner_globals & language_scanner_globals?
Don't they require the same declaration?
I think it's almost certain that they do - I just didn't have a test for
them, so I used the "if it ain't broke don't fix it" principle.
Also, how to reproduce it?
I compile C++ extensions quite often and do not see any problems.
Well you need to have an extension which references CG() or EG() from
C++ and build it with --disable-zts. So, compiling the sdo extension,
which refers to, for example, EG(uninitialized_zval_ptr), the link step
gives:
SDO_DataObject.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) struct _zend_executor_globals executor_globals"
(_imp?executor_globals@@3U_zend_executor_globals@@A)
Debug\php_sdo.dll : fatal error LNK1120: 1 unresolved externals
because the references are getting mangled. Putting them inside extern
"C" fixes this.
(my example was obviously on Windows, but the same should apply on *IX)
Also, how to reproduce it?
I compile C++ extensions quite often and do not see any problems.Well you need to have an extension which references CG() or EG() from
C++ and build it with --disable-zts. So, compiling the sdo extension,
which refers to, for example, EG(uninitialized_zval_ptr), the link step
gives:SDO_DataObject.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) struct _zend_executor_globals executor_globals"
(_imp?executor_globals@@3U_zend_executor_globals@@A)Debug\php_sdo.dll : fatal error LNK1120: 1 unresolved externals
because the references are getting mangled. Putting them inside extern
"C" fixes this.(my example was obviously on Windows, but the same should apply on *IX)
Seems to be Windows specific - it works fine with ICC and GCC on Linux.
Edin, could you please check this out?
--
Wbr,
Antony Dovgal