| Summary: | dev-libs/xapian-bindings-1.4.4 : php7/xapian_wrap.cc:1096:27: error: xapian_globals was not declared in this scope | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
| Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | knoeferl, mattst88, sam, whissi |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 669794 | ||
| Attachments: |
emerge-info.txt
dev-libs:xapian-bindings-1.4.4:20170716-010029.log.bz2 emerge-history.txt environment etc.portage.tbz2 logs.tbz2 temp.tbz2 PHP_TARGETS="php7-1" USE="php cli" emerge =dev-libs/xapian-bindings-1.4.7 PHP_TARGETS="php7-2" USE="php cli" emerge =dev-libs/xapian-bindings-1.4.7 |
||
Created attachment 484960 [details]
emerge-info.txt
Created attachment 484962 [details]
dev-libs:xapian-bindings-1.4.4:20170716-010029.log.bz2
Created attachment 484964 [details]
emerge-history.txt
Created attachment 484966 [details]
environment
Created attachment 484968 [details]
etc.portage.tbz2
Created attachment 484970 [details]
logs.tbz2
Created attachment 484972 [details]
temp.tbz2
IS there a known workaround for this issue? I am running iinto same problem and don't know how solve it. Still happening with 1.4.7 on x86. (In reply to HKnoeferl from comment #8) > IS there a known workaround for this issue? > I am running iinto same problem and don't know how solve it. Build with USE=-php. *** Bug 660488 has been marked as a duplicate of this bug. *** Created attachment 563908 [details]
PHP_TARGETS="php7-1" USE="php cli" emerge =dev-libs/xapian-bindings-1.4.7
Created attachment 563910 [details]
PHP_TARGETS="php7-2" USE="php cli" emerge =dev-libs/xapian-bindings-1.4.7
@whissi @mattst I'm going to need you're help here because I'm not sure why this "just works" for me. Both of the following built fine on amd64: 1) PHP_TARGETS="php7-1" USE="php cli" emerge =dev-libs/xapian-bindings-1.4.7 2) PHP_TARGETS="php7-2" USE="php cli" emerge =dev-libs/xapian-bindings-1.4.7 I thought it was an arch dependent problem, but matt says he can reproduce it on amd64. See the attached logs. I cannot reproduce on ~amd64 but still on x86. (In reply to Anthony Basile from comment #14) > @whissi @mattst > > I'm going to need you're help here because I'm not sure why this "just > works" for me. Both of the following built fine on amd64: Sometimes it's best to just look at the code. The code that causes the compile failure is php7/php7/xapian_wrap.cc around line 1096: ZEND_BEGIN_MODULE_GLOBALS(xapian) const char *error_msg; int error_code; ZEND_END_MODULE_GLOBALS(xapian) ZEND_DECLARE_MODULE_GLOBALS(xapian) #define SWIG_ErrorMsg() (xapian_globals.error_msg) #define SWIG_ErrorCode() (xapian_globals.error_code) I glanced in the php5 version of the code, and it contains #ifdef ZTS #define SWIG_ErrorMsg() TSRMG(xapian_globals_id, zend_xapian_globals *, error_msg ) #define SWIG_ErrorCode() TSRMG(xapian_globals_id, zend_xapian_globals *, error_code ) #else #define SWIG_ErrorMsg() (xapian_globals.error_msg) #define SWIG_ErrorCode() (xapian_globals.error_code) #endif which made me wonder what ZTS stood for. Evidently it's "Zend Thread Safety". In /usr/lib64/php7.2/include/php/Zend/zend_API.h there's an #ifdef ZTS immediately before the definition of the macro ZEND_DECLARE_MODULE_GLOBALS (previously seen immediately before our code in xapian that causes the compile error). Sure enough, building php with USE=-threads allows xapian-bindings to build for me. I see Toralf has USE=threads. I assume that you have USE=-threads and therefore are not seeing the error. (In reply to Matt Turner from comment #16) > (In reply to Anthony Basile from comment #14) > > @whissi @mattst > > > > I'm going to need you're help here because I'm not sure why this "just > > works" for me. Both of the following built fine on amd64: > > Sometimes it's best to just look at the code. The code that causes the > compile failure is php7/php7/xapian_wrap.cc around line 1096: > okay i've confirmed this (thanks!). i don't want to force USE=-threads for php if someone needs php bindings for xapian. i'll either try to come up with a patch myself or talk to upstream about it. (In reply to Matt Turner from comment #16) > I assume that you have USE=-threads and therefore are not seeing the error. Until upstream address this, I've forced dependence on php[-threads]. (In reply to Anthony Basile from comment #18) > (In reply to Matt Turner from comment #16) > > I assume that you have USE=-threads and therefore are not seeing the error. > > Until upstream address this, I've forced dependence on php[-threads]. I forwarded my fix to 1.4.11. So its the next candidate for stabilization. (In reply to Anthony Basile from comment #19) > (In reply to Anthony Basile from comment #18) > > (In reply to Matt Turner from comment #16) > > > I assume that you have USE=-threads and therefore are not seeing the error. > > > > Until upstream address this, I've forced dependence on php[-threads]. > > I forwarded my fix to 1.4.11. So its the next candidate for stabilization. Did your fix make it in? Did it make it into 1.4.11? I still see the dependency on php[threads] in 1.4.11.ebuild. (In reply to Matt Turner from comment #20) > (In reply to Anthony Basile from comment #19) > > (In reply to Anthony Basile from comment #18) > > > (In reply to Matt Turner from comment #16) > > > > I assume that you have USE=-threads and therefore are not seeing the error. > > > > > > Until upstream address this, I've forced dependence on php[-threads]. > > > > I forwarded my fix to 1.4.11. So its the next candidate for stabilization. > > Did your fix make it in? Did it make it into 1.4.11? I still see the > dependency on php[threads] in 1.4.11.ebuild. How are you getting that? Here's what I see in the ebuild (I checked on a couple of machines): php? ( dev-lang/php:=[-threads] ) That's in COMMONDEPEND which is included in DEPEND and RDEPEND. (In reply to Anthony Basile from comment #21) > (In reply to Matt Turner from comment #20) > > (In reply to Anthony Basile from comment #19) > > > (In reply to Anthony Basile from comment #18) > > > > (In reply to Matt Turner from comment #16) > > > > > I assume that you have USE=-threads and therefore are not seeing the error. > > > > > > > > Until upstream address this, I've forced dependence on php[-threads]. > > > > > > I forwarded my fix to 1.4.11. So its the next candidate for stabilization. > > > > Did your fix make it in? Did it make it into 1.4.11? I still see the > > dependency on php[threads] in 1.4.11.ebuild. > > How are you getting that? Here's what I see in the ebuild (I checked on a > couple of machines): > > php? ( dev-lang/php:=[-threads] ) > > That's in COMMONDEPEND which is included in DEPEND and RDEPEND. Sorry, right, I meant php[-threads]. Did you submit a fix upstream? Where is the patch/bug report? (In reply to Matt Turner from comment #22) > (In reply to Anthony Basile from comment #21) > > (In reply to Matt Turner from comment #20) > > > (In reply to Anthony Basile from comment #19) > > > > (In reply to Anthony Basile from comment #18) > > > > > (In reply to Matt Turner from comment #16) > > > > > > I assume that you have USE=-threads and therefore are not seeing the error. > > > > > > > > > > Until upstream address this, I've forced dependence on php[-threads]. > > > > > > > > I forwarded my fix to 1.4.11. So its the next candidate for stabilization. > > > > > > Did your fix make it in? Did it make it into 1.4.11? I still see the > > > dependency on php[threads] in 1.4.11.ebuild. > > > > How are you getting that? Here's what I see in the ebuild (I checked on a > > couple of machines): > > > > php? ( dev-lang/php:=[-threads] ) > > > > That's in COMMONDEPEND which is included in DEPEND and RDEPEND. > > Sorry, right, I meant php[-threads]. > > Did you submit a fix upstream? Where is the patch/bug report? I spoke with upstream and the problem should be fixed in 1.4.12 which I just added to the tree. Here's how I tested: 1) started with the latest stage3-amd64 2) i installed php[-threads] 3) i installed xapian-1.4.12 + xapian-bindings-1.4.12[php] - no problem 3) i reinstalled php[+threads] 4) i reinstalled xapian-bindings-1.4.12[php] - no problem I'd appreciate testing. Currently it passes 3 images. But 2 of them does not have php in the USE flags The 3rd has USE="php" with php[-threads] where this package builds fine too. I did not change manually the USE flags at a tinderbox after setup usually. @AnthonyB Is any work-around to use xapian-bindings-1.4.17 (amd64) on php7-4 CLI with switch +threads ?? |
libtool: compile: x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/lib64/php7.1/include/php -I/usr/lib64/php7.1/include/php/main -I/usr/lib64/php7.1/include/php/TSRM -I/usr/lib64/php7.1/include/php/Zend -I/usr/lib64/php7.1/include/php/ext -I/usr/lib64/php7.1/include/php/ext/date/lib -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -fvisibility=hidden -Werror=terminate -O2 -pipe -march=native -c php7/xapian_wrap.cc -fPIC -DPIC -o php7/.libs/xapian_wrap.o php7/xapian_wrap.cc: In function ‘void SWIG_FAIL()’: php7/xapian_wrap.cc:1096:27: error: ‘xapian_globals’ was not declared in this scope #define SWIG_ErrorCode() (xapian_globals.error_code) ^ php7/xapian_wrap.cc:1102:16: note: in expansion of macro ‘SWIG_ErrorCode’ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 13.0-desktop-gnome_abi32+64_20170706-200324 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.3.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) [3] pypy3 (fallback) [4] pypy (fallback) [5] jython2.7 (fallback) Available Ruby profiles: [1] ruby21 (with Rubygems) * [2] ruby22 (with Rubygems) java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.4.0 [icedtea-bin-8] 2) IcedTea JDK 3.4.0 (x86) [icedtea-bin-8-x86] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm [2] icedtea-bin-8-x86