[yocto] [oe] Problem building apache2 with php5

[Martin Bergek]

I created an image in more than a year ago with apache2 and php5. Now when I 
pull in all updates since then I realise that mod_php has been moved from the 
modphp recipe in meta-webserver to the php recipe in meta-oe.

I have created a php_5.6.12.bbappend file in which I have 

PACKAGECONFIG_append = " apache2”

Not entirely sure if this is the way to do it but when I try to build the php 
recipe I get a bunch of errors (see below) and would really appreciate some 
pointer on how to do it.

Would it be easier to build nginx with php support?


In file included from 
/home/martin/Yocto/poky/rpi/tmp/work/x86_64-linux/php-native/5.6.12-r0/php-5.6.12/sapi/apache2handler/mod_php5.c:26:0:
| 
/home/martin/Yocto/poky/rpi/tmp/work/x86_64-linux/php-native/5.6.12-r0/php-5.6.12/sapi/apache2handler/php_apache.h:24:19:
 fatal error: httpd.h: No such file or directory
| compilation terminated.
| In file included from 
/home/martin/Yocto/poky/rpi/tmp/work/x86_64-linux/php-native/5.6.12-r0/php-5.6.12/sapi/apache2handler/apache_config.c:25:0:
| 
/home/martin/Yocto/poky/rpi/tmp/work/x86_64-linux/php-native/5.6.12-r0/php-5.6.12/sapi/apache2handler/php_apache.h:24:19:
 fatal error: httpd.h: No such file or directory
| compilation terminated.
| Makefile:474: recipe for target 'sapi/apache2handler/mod_php5.lo' failed
| make: *** [sapi/apache2handler/mod_php5.lo] Error 1
| make: *** Waiting for unfinished jobs
| Makefile:478: recipe for target 'sapi/apache2handler/apache_config.lo' failed
| make: *** [sapi/apache2handler/apache_config.lo] Error 1
| 
/home/martin/Yocto/poky/rpi/tmp/work/x86_64-linux/php-native/5.6.12-r0/php-5.6.12/sapi/apache2handler/php_functions.c:33:23:
 fatal error: ap_config.h: No such file or directory
| compilation terminated.
| Makefile:480: recipe for target 'sapi/apache2handler/php_functions.lo' failed
| make: *** [sapi/apache2handler/php_functions.lo] Error 1
| 
/home/martin/Yocto/poky/rpi/tmp/work/x86_64-linux/php-native/5.6.12-r0/php-5.6.12/sapi/apache2handler/sapi_apache2.c:41:23:
 fatal error: ap_config.h: No such file or directory
| compilation terminated.
| Makefile:476: recipe for target 'sapi/apache2handler/sapi_apache2.lo' failed
| make: *** [sapi/apache2handler/sapi_apache2.lo] Error 1
| WARNING: exit code 1 from a shell command.
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (log file is located at 
/home/martin/Yocto/poky/rpi/tmp/work/x86_64-linux/php-native/5.6.12-r0/temp/log.do_compile.2418)


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python do_install fails on QEMUX86-64 and corei7-64 under Debian 8.0.3 isolated station

[Burton, Ross]

On 5 April 2016 at 23:17, Ronald Oakes  wrote:

> I'm basing off of poky-jethro-14.0.1.tar.bz as downloaded from
> yoctoproject.org.  I've also got meta-intel from the git of that name
> to support the corei7, my eventual target.
>

The full compile and install logs would be helpful.

Cheers,
Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Chris Trobridge]

I have a code base using gobject introspection that has been running fine on 
Alex's gobject-introspection-experimental branch on poky-contrib but is broken 
on 2.1 M3.
I am using it with python3 (3.5) but it isn't accessible with python27 either.  
It appears it may be partially installed for 2.7 but not at all for 3.5.
To simplify things, I have built core-image-full-cmdline on genericx86-64 and 
this gives the same result as my image:
=Poky (Yocto Project Reference Distro) 2.0+snapshot-20160406 
genericx86-64 console
genericx86-64 login: rootroot@genericx86-64:~# pythonPython 2.7.11 (default, 
Apr  6 2016, 10:05:21) [GCC 5.3.0] on linux2Type "help", "copyright", "credits" 
or "license" for more information.>>> import giTraceback (most recent call 
last):  File "", line 1, in   File 
"/usr/lib/python2.7/site-packages/gi/__init__.py", line 29, in 
import importlibImportError: No module named importlib>>> =
Is there something else I need to change to get gobject introspection to work 
with the RC or does this indicate a bug/omission?
Cheers,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Burton, Ross]

On 6 April 2016 at 11:53, Chris Trobridge 
wrote:

> ImportError: No module named importlib
>

Looks like python-gobject needs to depend on python-importlib.  Not sure
why that isn't in -core to be honest.

Can you add python-importlib to your image and see if it then works, or if
other modules are missing?

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Chris Trobridge]

Thanks Ross,
This did the trick for python 2.7, and "from gi.repository import GObject" 
works too.
It's still not installed for python 3.5.  I will see if I did anything specific 
to make that happen but it's odd that it worked before.
Regards,Chris

From: ross.bur...@intel.com
Date: Wed, 6 Apr 2016 11:57:10 +0100
Subject: Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2
To: christrobri...@hotmail.com
CC: yocto@yoctoproject.org


On 6 April 2016 at 11:53, Chris Trobridge  wrote:
ImportError: No module named importlib
Looks like python-gobject needs to depend on python-importlib.  Not sure why 
that isn't in -core to be honest.
Can you add python-importlib to your image and see if it then works, or if 
other modules are missing?
Ross  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Burton, Ross]

On 6 April 2016 at 12:19, Chris Trobridge 
wrote:

> This did the trick for python 2.7, and "from gi.repository import GObject"
> works too.
>

Can you send a patch to add this dependency to the pygobject package?

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python do_install fails on QEMUX86-64 and corei7-64 under Debian 8.0.3 isolated station

[Ronald Oakes]

Unfortunately, my build system is airgapped from the Internet, making
copying files into emails (or attaching them) extremely difficult.

RonO

On Wed, Apr 6, 2016 at 4:33 AM, Burton, Ross  wrote:
>
> On 5 April 2016 at 23:17, Ronald Oakes  wrote:
>>
>> I'm basing off of poky-jethro-14.0.1.tar.bz as downloaded from
>> yoctoproject.org.  I've also got meta-intel from the git of that name
>> to support the corei7, my eventual target.
>
>
> The full compile and install logs would be helpful.
>
> Cheers,
> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help Cross Compiling for AVR

[Washburn, David (washbudh)]

Hi All,

I am attempting to get the AVR Toolchain working inside of Yocto, but 
unfortunately I'm relatively new to Yocto and keep seeing various errors I 
cannot resolve. I was able to follow the instructions 
HERE to get 
everything working locally, but I'm seeing various issues inside of Yocto. I 
was able to get binutils configured and installed correctly but I haven't had 
any luck getting GCC installed. I am able to get pass the configure and compile 
stages in Yocto, but when I get to the install task, there's always a failure. 
The failure stems from this task below, which is a part of GCC:

# Add unwind.h, it comes from libgcc which we don't want to build again
install 
/build-bundle/poky/build/tmp/sysroots/x86_64-linux/usr/lib/avr/gcc/avr/4.9.3/include/unwind.h
/build-bundle/poky/build/tmp/work/cortexa53-vfp-neon-poky-linux-gnueabi/gcc-target-avr/4.9.3-r0/image/usr/lib/gcc/avr/4.9.3/include/

The reason it fails is because one of the two paths is always incorrect, no 
matter how I attempt to configure the build. If I configure the TARGET_SYS to 
be 'avr' during the install task, the path to 'unwind.h' becomes what is shown 
above, but the unwind header is not there. I *think* it's due to the fact that 
the TARGET_SYS was set to our default 'arm-poky-linux-gnueabi' during the 
configure stage. If I try to set the configuration to have a TARGET_SYS of 
'avr' it might resolve the issue, but unfortunately doing this causes the 
compile stage to fail with:
| Makefile:1571: t-oe: No such file or directory
| make[1]: *** No rule to make target `t-oe'.  Stop.

I am using a slightly modified version of the recipes shown in the link below.
 
https://lists.yoctoproject.org/pipermail/yocto/2014-December/022781.html

Lastly, here is a link to the GCC commit that talks about the need to copy over 
the file that is causing issues for me:
 https://gcc.gnu.org/ml/gcc-patches/2003-03/msg00367.html

Thanks in advance for any help you can give, and I apologize if any of this is 
unclear, I am still relatively new to Yocto.

Kind Regards,
  David Washburn



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [prelink-cross] [patch] gather.c: fix out of bounds access in maybe_pie()

[Alexander Miller]

The buffer passed to maybe_pie() holds only an ELF header and
space where one program header would fit (on 64bit), but the
program header table can be bigger or may be located somewhere
else. The function however loops over the program headers
without checking their position; if it doesn't stop on the
first header it reads random garbage from the stack, and for
large offsets it will segfault.

This patch changes the following:
* passes buffer size and file descriptor as additional
  parameters to maybe_pie();
* ensure that all data access stays inside the buffer's bounds;
* read more data from file if necessary;
* check and use the ELF header's e_phentsize member;
* add some more sanity checks;
* add a few variables for less repetitive code;
* slightly increase e_ident size such that one more program
  header type fits and reloading data becomes less likely.

--- prelink-cross-20151030/src/gather.c
+++ prelink-cross-20151030/src/gather.c
@@ -645,59 +645,89 @@ add_dir_to_dirlist (const char *name, de
   return 0;
 }
 
-/* Determine if a buffer holding an ELF header and program header
-   table may be that of a position-independent executable.  */
+/* Determine if a buffer holding an ELF header and the program header
+   table in the buffer or file may be that of a position-independent
+   executable.  */
 static int
-maybe_pie (unsigned char *e_ident, int big_endian, int sixty_four)
+maybe_pie (unsigned char *e_ident, size_t data_length, int fd,
+  int big_endian, int sixty_four)
 {
   uint16_t num_phdrs;
   uint16_t phdr;
   size_t p_type_offset;
   size_t phnum_offset;
+  off_t phdr_offset;
+  size_t phentsize_offset;
+  uint16_t phentsize;
+  size_t phdr_size;
   unsigned char *phdr_table;
-  unsigned char *this_phdr;
+  size_t this_offset;
+  unsigned char buffer[0x1000];
 
   if (sixty_four)
 {
-  uint64_t phdr_offset;
-  
+  unsigned char *phoff = e_ident + offsetof (Elf64_Ehdr, e_phoff);
+  phdr_size = sizeof (Elf64_Phdr);
   p_type_offset = offsetof (Elf64_Phdr, p_type);
   phnum_offset = offsetof (Elf64_Ehdr, e_phnum);
+  phentsize_offset = offsetof (Elf64_Ehdr, e_phentsize);
   if (big_endian)
-phdr_offset = buf_read_ube64 (&e_ident [offsetof (Elf64_Ehdr,
- e_phoff)]);
+phdr_offset = buf_read_ube64 (phoff);
   else
-phdr_offset = buf_read_ule64 (&e_ident [offsetof (Elf64_Ehdr,
- e_phoff)]);
-  phdr_table = e_ident + phdr_offset;
+phdr_offset = buf_read_ule64 (phoff);
+  if (phdr_offset < sizeof (Elf64_Ehdr))
+   return 0;
 }
   else
 {
-  uint32_t phdr_offset;
-  
+  unsigned char *phoff = e_ident + offsetof (Elf32_Ehdr, e_phoff);
+  phdr_size = sizeof (Elf32_Phdr);
   p_type_offset = offsetof (Elf32_Phdr, p_type);
   phnum_offset = offsetof (Elf32_Ehdr, e_phnum);
+  phentsize_offset = offsetof (Elf32_Ehdr, e_phentsize);
   if (big_endian)
-phdr_offset = buf_read_ube32 (&e_ident [offsetof (Elf32_Ehdr,
- e_phoff)]);
+phdr_offset = buf_read_ube32 (phoff);
   else
-phdr_offset = buf_read_ule32 (&e_ident [offsetof (Elf32_Ehdr,
- e_phoff)]);
-  phdr_table = e_ident + phdr_offset;
-}
-
-  this_phdr = phdr_table;
+phdr_offset = buf_read_ule32 (phoff);
+  if (phdr_offset < sizeof (Elf32_Ehdr))
+   return 0;
+ }
 
   if (big_endian)
-num_phdrs = buf_read_ube16 (&e_ident [phnum_offset]);
+{
+  num_phdrs = buf_read_ube16 (e_ident + phnum_offset);
+  phentsize = buf_read_ube16 (e_ident + phentsize_offset);
+}
   else
-num_phdrs = buf_read_ule16 (&e_ident [phnum_offset]);
-
-  for (phdr = 0; phdr < num_phdrs; phdr++)
 {
-  unsigned char *p_type_start = this_phdr + p_type_offset;
+  num_phdrs = buf_read_ule16 (e_ident + phnum_offset);
+  phentsize = buf_read_ule16 (e_ident + phentsize_offset);
+}
+  if (num_phdrs == 0 || phentsize < phdr_size)
+return 0;
+  /* TODO: check that phdr_offset + phentsize * num_phdrs doesn't overflow */
+
+  phdr_table = e_ident;
+  this_offset = phdr_offset < data_length ? phdr_offset : data_length;
+  for (phdr = 0; phdr < num_phdrs; phdr++, this_offset += phentsize)
+{
+  unsigned char *p_type_start;
   uint32_t p_type;
-  
+
+  if (this_offset + p_type_offset + sizeof (int32_t) > data_length)
+   {
+ /* Read more headers from file */
+ ssize_t read_bytes = pread (fd, buffer, sizeof(buffer),
+ phdr_offset + phdr * (off_t) phentsize);
+ if (read_bytes < phentsize)
+   return 0;
+
+ data_length = read_bytes;
+ phdr_table = buffer;
+ this_offset = 0;
+   }
+  
+  p_type_start = phdr_table + this_offset + p_type_offset

Re: [yocto] Python do_install fails on QEMUX86-64 and corei7-64 under Debian 8.0.3 isolated station

[Burton, Ross]

On 6 April 2016 at 15:27, Ronald Oakes  wrote:

> Unfortunately, my build system is airgapped from the Internet, making
> copying files into emails (or attaching them) extremely difficult.
>

Can you not put them on a USB stick?

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Chris Trobridge]

> From: ross.bur...@intel.com
> Date: Wed, 6 Apr 2016 12:22:39 +0100
> Subject: Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2
> To: christrobri...@hotmail.com
> CC: yocto@yoctoproject.org
>
>
> On 6 April 2016 at 12:19, Chris Trobridge
> mailto:christrobri...@hotmail.com>> wrote:
> This did the trick for python 2.7, and "from gi.repository import
> GObject" works too.
>
> Can you send a patch to add this dependency to the pygobject package?
>
> Ross

I will try to sort that out tomorrow (p...@yoctoproject.org, right?).

Regarding python3, whenever I change the "--with-python" option to something 
other than "python2.7" then I get an error.

If I specify python3.5 then the error is that the build cannot find python3.5.  
If I set it to python3.4 (which is installed on the host) then I get an error 
about system directory poisoning.

This suggests to me that the recipe seems to need both host and target python 
for this to work.  It worked before so I will look tomorrow at the experimental 
branch and see what's different, if anything.  I've deleted that branch here 
and it is gone from git.

Regards,
Chris

  
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Burton, Ross]

On 6 April 2016 at 16:45, Chris Trobridge 
wrote:

> I will try to sort that out tomorrow (p...@yoctoproject.org, right?).
>

No, openembedded-c...@lists.openembedded.org

Regarding python3, whenever I change the "--with-python" option to
> something other than "python2.7" then I get an error.
>

You need to change the inherits to pull in python3native.  Sadly flipping
between py2 and py3 isn't trivial.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Sharing Sstate cache among different platform architectures

[Santosh Y]

Hello,

Can sstate cache be shared among builds for different architectures like
x86 & PowerPC?

Thanks.
Santosh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python do_install fails on QEMUX86-64 and corei7-64 under Debian 8.0.3 isolated station

[Ronald Oakes]

Alas, not legally (government contract).  I might be able to burn them
to CD, but I'd still have to bring them home to email them.

For what it's worth, I may be able to work around this by using the
Poky-Tiny distribution, which is closer to what I'll need for the
minimalist system we need in the end.

RonO

On Wed, Apr 6, 2016 at 9:36 AM, Burton, Ross  wrote:
>
> On 6 April 2016 at 15:27, Ronald Oakes  wrote:
>>
>> Unfortunately, my build system is airgapped from the Internet, making
>> copying files into emails (or attaching them) extremely difficult.
>
>
> Can you not put them on a USB stick?
>
> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Sharing Sstate cache among different platform architectures

[Burton, Ross]

On 6 April 2016 at 18:18, Santosh Y  wrote:

> Can sstate cache be shared among builds for different architectures like
> x86 & PowerPC?
>
> Yes (and different host distros).

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python do_install fails on QEMUX86-64 and corei7-64 under Debian 8.0.3 isolated station

[Burton, Ross]

On 6 April 2016 at 20:55, Ronald Oakes  wrote:

> For what it's worth, I may be able to work around this by using the
> Poky-Tiny distribution, which is closer to what I'll need for the
> minimalist system we need in the end.
>

If you need a minimal system then you might want to look at oe-core from
git, which has musl support integrated.  musl appears to be superiour to
uclibc and we'll be releasing 2.1 this month.  There's a good chance that
uclibc will be removed from oe-core entirely for the 2.2 release as musl is
only slightly larger than uclibc but more capable.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python do_install fails on QEMUX86-64 and corei7-64 under Debian 8.0.3 isolated station

[Andre McCurdy]

On Wed, Apr 6, 2016 at 3:23 PM, Burton, Ross  wrote:
>
> On 6 April 2016 at 20:55, Ronald Oakes  wrote:
>>
>> For what it's worth, I may be able to work around this by using the
>> Poky-Tiny distribution, which is closer to what I'll need for the
>> minimalist system we need in the end.
>
> If you need a minimal system then you might want to look at oe-core from
> git, which has musl support integrated.  musl appears to be superiour to
> uclibc and we'll be releasing 2.1 this month.  There's a good chance that
> uclibc will be removed from oe-core entirely for the 2.2 release as musl is
> only slightly larger than uclibc but more capable.

You could also perhaps try setting DEFAULTTUNE to core2-64 instead of corei7-64.

If your development system is able to run binaries compiled for core2
then the problem might just become hidden again.

Out of interest, what is the CPU in your development system?

>
> Ross
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Sharing Sstate cache among different platform architectures

[Santosh Y]

On Apr 7, 2016 1:44 AM, "Burton, Ross"  wrote:
>
>
> On 6 April 2016 at 18:18, Santosh Y  wrote:
>>
>> Can sstate cache be shared among builds for different architectures like
x86 & PowerPC?
>
> Yes (and different host distros).
>
> Ross

Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Release Candidate Build for yocto-2.1.rc1.rc1 now available.

[Poky Build User]

A release candidate build for yocto-2.1.rc1 is now available at:

 
http://autobuilder.yoctoproject.org/pub/releases/yocto-2.1.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 7d2b2f5b644a2729c75b8ecb38345c9668d2c8bb 
meta-fsl-arm : cec4c47e33979631e85e2c933cea5182da61ad82 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt4 : 4058b0773381f894d915ea3dfac5fe052d82a9a7 
meta-qt3 : 7d958b928a4a38a186746fabbc0d8169dd8bb3a6 
meta-fsl-ppc : 2642cf5e8a6f8d11603acf016b8c075ebce00ec0 
poky : 296dfbc9b3a3c0ed64b8e748c2868928b9c2aa8b 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto