[oe] [meta-webserver][PATCH 1/3] apache2: fix configuration

[Koen Kooi]

Op 9 okt. 2012, om 14:30 heeft Paul Eggleton <paul.eggleton at linux.intel.com> het volgende geschreven:

> On Tuesday 09 October 2012 14:23:43 Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Op 07-10-12 13:13, Paul Eggleton schreef:
>>> * Include conf files in /etc/apache2/modules.d and conf.d * Add -D PHP5
>>> to options so that PHP is enabled if installed * Fix "reload" action in
>>> initscript
>>> 
>>> Signed-off-by: Paul Eggleton <paul.eggleton at linux.intel.com>
>> 
>> This is more likely related to your previous patch, but:
>> | /bin/sh:
>> /OE/tentacle/build/tmp-angstrom_next-eglibc/work/armv7a-vfp-neon-angstrom-li
>> nux-gnueabi/apr-1.4.6-r1/apr-1.4.6/arm-angstrom-linux-gnueabi-libtool: No
>> such file or directory
>> 
>> | make[3]: *** [unixd.lo] Error 127
>> | make[3]: Leaving directory
>> 
>> `/OE/tentacle/build/tmp-angstrom_next-eglibc/work/armv7a-vfp-neon-angstrom-l
>> inux-gnueabi/apache2-2.4.2-r1/httpd-2.4.2/os/unix'
>> | make[2]: *** [all-recursive] Error 1
>> | make[2]: Leaving directory
>> 
>> `/OE/tentacle/build/tmp-angstrom_next-eglibc/work/armv7a-vfp-neon-angstrom-l
>> inux-gnueabi/apache2-2.4.2-r1/httpd-2.4.2/os/unix'
>> | make[1]: *** [all-recursive] Error 1
>> | make[1]: Leaving directory
>> 
>> `/OE/tentacle/build/tmp-angstrom_next-eglibc/work/armv7a-vfp-neon-angstrom-l
>> inux-gnueabi/apache2-2.4.2-r1/httpd-2.4.2/os'
>> | make: *** [all-recursive] Error 1
>> | ERROR: oe_runmake failed
>> | ERROR: Function failed: do_compile (see
>> 
>> /OE/tentacle/build/tmp-angstrom_next-eglibc/work/armv7a-vfp-neon-angstrom-li
>> nux-gnueabi/apache2-2.4.2-r1/temp/log.do_compile.591 for further
>> information)
>> ERROR: Task 6
>> (/OE/tentacle/sources/meta-openembedded/meta-webserver/recipes-httpd/apache2
>> /apache2_2.4.2.bb, do_compile) failed with exit code '1'
> 
> I'm guessing you are using rm_work? Obviously it's not supposed to be 
> referring to anything in the WORKDIR for another recipe, but it would at least 
> explain why I did not see that failure here.

I am indeed using rm_work.