php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #61177 Unable to compile when including sapi/embed/php_embed.h
Submitted: 2012-02-24 11:43 UTC Modified: 2012-03-05 00:34 UTC
From: jmc at chakra-project dot org Assigned: pajoye
Status: Assigned Package: Compile Failure
PHP Version: 5.3.10 OS: Windows XP Professional SP3
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2012-02-24 11:43 UTC] jmc at chakra-project dot org
Description:
------------
After having compiled PHP from the 5_3_10 SVN branch as described in an earlier 
bug report (https://bugs.php.net/bug.php?id=61175), I've set up my project to 
point to the include directories from the extracted snapshot archives and I have 
defined the PHP_WIN32 and ZEND_WIN32 macros. After this, I launched the program 
compilation and it failed.

The software configuration is the same as described in the other bug report.

Test script:
---------------
This is the source file where the compilation stops with an error: http://paste.kde.org/428270/00820021/

Expected result:
----------------
The compilation should complete flawlessly (as it does on a Linux platform with 
the same compilation options and the same code).

Actual result:
--------------
The compilation fails with errors.

Compilation error log: http://paste.kde.org/428264/33008173/

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-02-24 11:55 UTC] cataphract@php.net
Can you try surrounding the include with extern "C" { ... }

This is probably a bug nevertheless because the headers should ensure this.
 [2012-02-24 12:01 UTC] jmc at chakra-project dot org
Yes, I've tried to change the #include directive like this:

extern "C" {
    #include <sapi/embed/php_embed.h>
}

and it gave me the same results.
 [2012-03-02 22:17 UTC] jmc at chakra-project dot org
It turns out that the problem is the same as described into this bug report:

https://bugs.php.net/bug.php?id=39130

Manually defining the _USE_32BIT_TIME_T macro at compile time allowed me to get 
past that error.

Something is still off, anyway, since I now get errors like these:

Window.cpp.obj : error LNK2005: _acosl already defined in PhpEmbed.cpp.obj
Window.cpp.obj : error LNK2005: _asinl already defined in PhpEmbed.cpp.obj
Window.cpp.obj : error LNK2005: _atanl already defined in PhpEmbed.cpp.obj
Window.cpp.obj : error LNK2005: _atan2l already defined in PhpEmbed.cpp.obj
...

and so on, seemingly caused by the functions defined in the php_math.h header in 
some way.
 [2012-03-03 02:16 UTC] jmc at chakra-project dot org
"Solved" that problem by including <math.h> before any PHP header, so that those functions will not get redefined. Also found out that PHP messes up with the "inline" keyword, so it won't play well with Qt headers when they are included after the PHP ones.

Seems like the only remaining problem is now this linkage failure:

Window.cpp.obj : error LNK2001: unresolved external symbol __imp__executor_globals

But I'm lost now.
 [2012-03-05 00:34 UTC] johannes@php.net
-Assigned To: +Assigned To: pajoye
 [2012-03-05 00:34 UTC] johannes@php.net
That error indicates you're most likely mixing a thread-safe PHP build with a non-thread safe build. (PHP build thread-safe, your application expecting a non-threaded PHP build)

I'm not sure how this is supposed to work on Windows, though. Maybe Pierre has some tips. On Linux/Unix the generated php_config.h has the proper settings.
 [2012-03-11 15:28 UTC] jmc at chakra-project dot org
PHP was built as non-thread safe, and I haven't manually redefined the ZTS macro, so I bet it's not the case.

I've given up on the embedding way for now, and I'm using PHP as an external interpreter, FWIW.
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Tue Aug 29 15:01:52 2017 UTC