Cross compile PHP [closed]
Asked Answered
T

0

14

I have downloaded the PHP 5.4.0 source, extracted it and moved into the source folder.

I do a configure with:

./configure --build=x86_64-unknown-linux-gnu --host=arm-linux-uclibcgnueabi --prefix=/usr/arm/www CC="arm-linux-uclibcgnueabi-gcc --sysroot=/toolchains/gnu_cortex-a9_tools/"  --disable-libxml --disable-dom  --without-iconv --without-openssl --disable-simplexml --disable-xml --disable-xmlreader --disable-xmlwriter --without-pear --without-sqlite3 --disable-pdo --without-pdo-sqlite --disable-phar  --with-config-file-path=/etc/

Followed by

make

no errors, everything runs fine. Next i do a make install.

make install

Again everything runs fine. i move it to the target platform and run

/usr/arm/www/bin/php -v
PHP 5.4.0 (cli) (built: Aug 15 2012 16:07:41) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

I test a simple home page with my webserver and directly with php.

<?php echo "hello" ?>
# php index.php
hello

it works as expected. next i test:

<?php
$output = shell_exec('ls -lart');
echo "<pre>$output</pre>";
?>

oh noes~

# php shell.php 

Segmentation fault

I teset another script:

#!/bin/php
<?php

echo "hello";
$handle = fopen("info.txt", "r");
echo $handle;
?>

Same result:

# php index.php 
helloSegmentation fault

do i have a php.ini?

# /usr/arm/www/bin/php --ini
Configuration File (php.ini) Path: /etc/
Loaded Configuration File:         /etc/php.ini

yes, and no disabled functions. testing strace /usr/arm/www/bin/php index.php

lstat("/srv/www/info.txt", {st_mode=S_IFREG|0644, st_size=20, ...}) = 0
open("/srv/www/info.txt", O_RDONLY)     = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=20, ...}) = 0
lseek(3, 10, SEEK_CUR)                  = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

the file info.txt exists and it got premission to read/write to it.

Testing strace /usr/arm/www/bin/php shell.php

fcntl64(3, F_GETFL)                     = 0 (flags O_RDONLY)
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7e31fddc) = -1 EINVAL (Invalid argument)
vfork()                                 = 3324
close(4)                                = 0
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
read(3, "total 24\n-rw-rw-r--    1 1001    "..., 8192) = 468
read(3, ""..., 8192)                    = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
close(3)                                = 0
wait4(3324, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3324
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

if i run the index.php through gdb it gives me:

Starting program: /usr/arm/www/bin/php index.php
hello
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x2ac7a040) at /home/maiden/Downloads/php-5.4.0/Zend/zend.h:391
391 /home/maiden/Downloads/php-5.4.0/Zend/zend.h: No such file or directory.
    in /home/maiden/Downloads/php-5.4.0/Zend/zend.h

gdb gives me this from shell.php Starting program: /usr/arm/www/bin/php shell.php

Program received signal SIGSEGV, Segmentation fault.

zend_do_fcall_common_helper_SPEC (execute_data=0x2ab76040) at /home/maiden/Downloads/php-5.4.0/Zend/zend.h:391
391 in /home/maiden/Downloads/php-5.4.0/Zend/zend.h

zend.h is located in /usr/arm/www/include/php/Zend/ obviously something went wrong during cross compilation. what have i missed? i do not find any configure flag to correct this and creating a symlink to the desired location removes the gdb output but php still segfaults.

Thanks for any help!

UPDATE:

# valgrind php test.php
==2181== Memcheck, a memory error detector
==2181== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2181== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==2181== Command: php test.php
==2181==
==2181== Conditional jump or move depends on uninitialised value(s)
==2181==    at 0x4004EC8: ??? (in /lib/ld-uClibc-0.9.30-nptl.so)
==2181==
==2181== Invalid read of size 4
==2181==    at 0x4004D48: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.30-nptl.so)
==2181==  Address 0x7d4cc304 is just below the stack ptr.  To suppress, use: --workaround-gcc296-bugs=yes
==2181==
==2181== Invalid read of size 4
==2181==    at 0x48C348C: __uClibc_main (in /lib/libuClibc-0.9.30-nptl.so)
==2181==  Address 0x7d4cc554 is just below the stack ptr.  To suppress, use: --workaround-gcc296-bugs=yes
==2181==
==2181== Invalid write of size 4
==2181==    at 0x233010: __eqdf2 (ieee754-df.S:1120)
==2181==  Address 0x7d4cb0bc is just below the stack ptr.  To suppress, use: --workaround-gcc296-bugs=yes
==2181==
Warning: shell_exec(): Unable to execute 'ls -lart' in /test.php on line 3
==2181== Invalid read of size 4
==2181==    at 0x1FF1AC: zend_do_fcall_common_helper_SPEC (zend.h:391)
==2181==    by 0x1F3D17: execute (zend_vm_execute.h:410)
==2181==    by 0x18B217: zend_execute_scripts (zend.c:1279)
==2181==    by 0x1365BB: php_execute_script (main.c:2473)
==2181==    by 0x22B52B: do_cli (php_cli.c:988)
==2181==    by 0x22BD4B: main (php_cli.c:1364)
==2181==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==2181==
Segmentation fault

Update2

re-run valgrind with memcheck, got about the same output as before but this was new:

php: can't resolve symbol '__libc_freeres'

Update3

While valgrind have failed me, i continued with gdb, i created the folder /home/maiden/..etc on my target system and copied over the content of my php/include folder and re-run gdb. now i get this error message:

(gdb) run index.php 
Starting program: /bin/php index.php
hello
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x2ab34040) at /home/maiden/Downloads/php-5.4.5/Zend/zend.h:391
warning: Source file is more recent than executable.
391     return --pz->refcount__gc;

this is very similar to what sixeightzero wrote in the comments yesterday. I have now tried PHP version 5.3.5, 5.4.0, 5.4.5 same error on all.

This topic have been CLOSED! :( Continued on: https://serverfault.com/questions/418521/cross-compile-php [CLOSED] and now on: Cross compile PHP with UCLIBC

Teleview answered 15/8, 2012 at 14:47 Comment(15)
Have you had a quick look to try to spot anything obvious that might be the result of compiling for ARM?Fremd
yes, have still not seen anything that might cause this. /home/maiden is located on the development machine. those paths should not exist in the compiled binary running on the target...Teleview
Install valgrind and see what lib is called when the segfault occurs. Most likely a sub library which isn't arm compatible.Keenan
I rather not spend time on cross compiling valgrind. But i think i will have to do it tomorrow if nothing else shows up here..Teleview
That line looks like it refers to memory management (zend.h:391), --pz->refcount__gc where it deletes the reference. Looking into this too.. curious to see where it ends upKeenan
Well, i have not managed to configure valgrind yet, i get: checking for a supported CPU... no (arm) configure: error: Unsupported host architecture. SorryTeleview
rewrote configure script for valgrind to accept my configure host flag ;), valgrind is now working :DTeleview
Out of curiosity, are there any special bits set on the filesystem that is mounted where you try to execute your PHP code? I don't know enough about valgrind to give a good interpretation of the shell_exec() warning. But, your strace log shows the result of ls being read so might it be something really esoteric about error handling when file operations don't behave as expected?Fremd
I do not know, the filesystem is mounted via NFS so maybe?Teleview
Another possibility is that there is some bug in the php build system where it used the build system's structure sizes rather than the arm platform you're targeting. That memory behavior looks like the size of something is wrong and it's off when trying to access a data structure.Waldrop
I would try defining zend_always_inline to blank in zend.h and see if it behaves differently. Just a way to see if the bug is in the logic of the code or not.Novak
@j08691 @ sixeightzero I really don't understand why you thought that this would be on topic for serverfault. Most sysadmins wouldn't be compiling this from source we'd be using the packages provided by the relevant distro. Debugging segfaults in code like this is very firmly development and most likely in the php developers realm. The OP should really contact them or at least use their mailing lists php.net/mailing-lists.phpBaring
@JamWaffles please see my comment above re migrations.Baring
@JürgenThelen please see my comment above re migrationsBaring
@ughoavgfhw please see my comment above re migrationsBaring

© 2022 - 2024 — McMap. All rights reserved.