diff mbox

php: force cross-compilation

Message ID 1340317344-22807-1-git-send-email-thomas.petazzoni@free-electrons.com
State Accepted
Commit 7944f19740497e68287b612db6a63e94e3cc1fe5
Headers show

Commit Message

Thomas Petazzoni June 21, 2012, 10:22 p.m. UTC
This fixes build problems like
http://autobuild.buildroot.org/results/e3c5815766fdcf3f13b06fa0758ec418618ac4be/build-end.log.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/php/php-force-cross-compile.patch |   50 +++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 package/php/php-force-cross-compile.patch

Comments

Peter Korsgaard June 23, 2012, 8:11 p.m. UTC | #1
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> This fixes build problems like
 Thomas> http://autobuild.buildroot.org/results/e3c5815766fdcf3f13b06fa0758ec418618ac4be/build-end.log.

Thanks, committed. It would be good to add cache support to
ac_cv_prog_cc_cross, so we could just pass ac_cv_prog_cc_cross=yes in
PHP_CONF_ENV, but ok.
Thomas Petazzoni June 25, 2012, 7:12 a.m. UTC | #2
Le Sat, 23 Jun 2012 22:11:06 +0200,
Peter Korsgaard <jacmet@uclibc.org> a écrit :

> Thanks, committed. It would be good to add cache support to
> ac_cv_prog_cc_cross, so we could just pass ac_cv_prog_cc_cross=yes in
> PHP_CONF_ENV, but ok.

Well, since we can't easily change the configure.in file and regenerate
the configure script (due to the very old version of autoconf that PHP
developers use), I'm not sure it's really worth the effort. But on the
other hand, it's true that it would potentially make it possible to have
the patch upstream.

Thomas
Peter Korsgaard June 25, 2012, 8:04 a.m. UTC | #3
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> Well, since we can't easily change the configure.in file and
 Thomas> regenerate the configure script (due to the very old version of
 Thomas> autoconf that PHP developers use), I'm not sure it's really
 Thomas> worth the effort. But on the other hand, it's true that it
 Thomas> would potentially make it possible to have the patch upstream.

True. Looking at the autobuilder results it seems htop has a similar
problem (I don't quite understand why it cannot find /proc/stat on your
builder though):

http://autobuild.buildroot.net/results/7d670efa247dfcbcbf6cd088d1157779af441333/build-end.log
Thomas Petazzoni June 25, 2012, 8:06 a.m. UTC | #4
Le Mon, 25 Jun 2012 10:04:42 +0200,
Peter Korsgaard <jacmet@uclibc.org> a écrit :

> True. Looking at the autobuilder results it seems htop has a similar
> problem (I don't quite understand why it cannot find /proc/stat on your
> builder though):
> 
> http://autobuild.buildroot.net/results/7d670efa247dfcbcbf6cd088d1157779af441333/build-end.log

I'm building in a chroot, and I don't have /proc mounted. I'm not sure
it's a useful scenario to support?

Thomas
Peter Korsgaard June 25, 2012, 8:50 a.m. UTC | #5
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Le Mon, 25 Jun 2012 10:04:42 +0200,
 Thomas> Peter Korsgaard <jacmet@uclibc.org> a écrit :

 >> True. Looking at the autobuilder results it seems htop has a similar
 >> problem (I don't quite understand why it cannot find /proc/stat on your
 >> builder though):
 >> 
 >> http://autobuild.buildroot.net/results/7d670efa247dfcbcbf6cd088d1157779af441333/build-end.log

 Thomas> I'm building in a chroot, and I don't have /proc mounted. I'm
 Thomas> not sure it's a useful scenario to support?

Hmm, we could fix this particular problem similar to how you did for
php, but chances are other native tools would want to poke in /proc. Any
specific reason you cannot mount /proc to get a more representative
setup?
Thomas Petazzoni June 25, 2012, 9:06 a.m. UTC | #6
Le Mon, 25 Jun 2012 10:50:21 +0200,
Peter Korsgaard <jacmet@uclibc.org> a écrit :

> Hmm, we could fix this particular problem similar to how you did for
> php, but chances are other native tools would want to poke in /proc. Any
> specific reason you cannot mount /proc to get a more representative
> setup?

No, it's just due to some too limited shell script to enter the chroot,
nothing else.

Thomas
diff mbox

Patch

diff --git a/package/php/php-force-cross-compile.patch b/package/php/php-force-cross-compile.patch
new file mode 100644
index 0000000..f14b477
--- /dev/null
+++ b/package/php/php-force-cross-compile.patch
@@ -0,0 +1,50 @@ 
+php: force cross-compilation
+
+In its configure script, PHP detects whether we're cross-compiling or
+not, by compiling and running a simple C program. Depending on whether
+cross-compiling has been detected or not, then PHP enables or disables
+the AC_TRY_RUN tests (which verify the availability of something by
+*executing* a program, which, by definition, cannot work in
+cross-compilation mode).
+
+This works just fine when the target architecture is ARM or PowerPC
+and the build machine is x86 or x86_64. Unfortunately, when the target
+architecture is x86_64 and the build machine is also x86_64, the
+cross-compilation mode detection concludes that we are not
+cross-compiling, because it succeeds in running this small program.
+
+However, while it succeeds in running this basic small program, some
+other programs executed later through AC_TRY_RUN tests do not work,
+because they have target library dependencies that are not available
+on the build machine. For example, the libxml2 test fails to *run*
+because libxml2 is not available on the build machine, only in the
+target/staging directories. So trying to run a program linked against
+libxml2, on the build machine, simply doesn't make sense.
+
+We fix this problem by just forcing PHP to think that we're
+cross-compiling (which is always the case with Buildroot, as we're at
+the moment never building PHP for the host). Unfortunately, the
+configure.in file dates back from the autoconf 2.13 era, so the
+configure script does not understand the ac_cv_prog_cc_cross cache
+variable, and we cannot easily regenerate the configure script using
+our package autoconf version. The easiest solution is therefore to
+simply patch the configure script to make the cross-compilation test
+fail: we replace the execution of the program by a call to false,
+which always fail, leading the configure script to understand that we
+*are* cross-compiling.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+Index: b/configure
+===================================================================
+--- a/configure
++++ b/configure
+@@ -2387,7 +2387,7 @@
+ if { (eval echo configure:2388: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+   ac_cv_prog_cc_works=yes
+   # If we can't run a trivial program, we are probably using a cross compiler.
+-  if (./conftest; exit) 2>/dev/null; then
++  if (false; exit) 2>/dev/null; then
+     ac_cv_prog_cc_cross=no
+   else
+     ac_cv_prog_cc_cross=yes