Re: Apache segmentation fault when loading libphp7.so

On 13.08.2020 at 11:52, Kai Fürstenberg wrote: > Am 13.08.2020 um 10:31 schrieb Christoph M. Becker: > >> On 12.08.2020 at 18:09, Kai Fürstenberg wrote: >> >>> Hello everybody, >>> >>> and thank you for you help so far. >>> >>> I played around with gdb a little bit. >>> >>> I re-configured php the way I did in 7.2 (just with some slight >>> modifications), to use mysql, gd and some other things. >>> >>> But this time, httpd stops with >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> resolve_stripslashes () at >>> /usr/src/apache_testing/php-7.4.9/Zend/zend_cpuinfo.h:157 >>> 157             __builtin_cpu_init(); >>> >>> Before I had the fault >>> >>> #0  resolve_base64_decode () at >>> /usr/src/apache_testing/php-7.4.9/Zend/zend_cpuinfo.h:141 >>> >>> Line 141 of zend_cpuinfo.h is the very same command >>> __builtin_cpu_init() >>> >>> It seems, that exactly this command __builtin_cpu_init() fails for some >>> reason... >> >> Did you check config.log? There is a test for __builtin_cpu_init() >> availability[1] which apparently succeeds on your system, but it's worth >> to actually look that up in config.log. Maybe this test should use >> AC_RUN_IFELSE instead of AC_LINK_IFELSE (and have the then and else >> branch of the ternary operator swapped)? >> >> [1] >> >> <https://github.com/php/php-src/blob/php-7.3.21/acinclude.m4#L3261-L3278> > > config.log: > configure:13702: checking for __builtin_cpu_init > configure:13718: cc -o conftest -g -O2 -fvisibility=hidden -pthread > -D_REENTRANT conftest.c -lm -ldl -lpthread >&5 > configure:13718: $? = 0 > configure:13721: result: yes > configure:13741: checking for __builtin_cpu_supports > configure:13757: cc -o conftest -g -O2 -fvisibility=hidden -pthread > -D_REENTRANT conftest.c -lm -ldl -lpthread >&5 > configure:13757: $? = 0 > configure:13760: result: yes > > I just don't understand what you mean with the link... I basically suggested to apply <https://gist.github.com/cmb69/3fd0106ce78446c9e10e54eec21a4d82>, and to run ./configure again. Would the result still be "yes"? -- Christoph M. Becker