[PATCH] pango: add libpcre to DEPENDS

[PATCH] pango: add libpcre to DEPENDS

[Ioan-Adrian Ratiu]

pango has a build time dependency on libpcre which causes a build
race, if pango gets built before libpcre, it fails with the error:

| ./gen-all-unicode > all-unicode.txt
| ./gen-all-unicode: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory
| Makefile:1459: recipe for target 'all-unicode.txt' failed
| make[2]: *** [all-unicode.txt] Error 127
| make[2]: *** Waiting for unfinished jobs....
| make[2]: Leaving directory '/mnt/build/jenkins-jobs/nilrt_OE_core_x64-pname/workspace/build/tmp-glibc/work/core2-64-nilrt-linux/pango/1.40.1-r0/build/tests'
| Makefile:576: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory '/mnt/build/jenkins-jobs/nilrt_OE_core_x64-pname/workspace/build/tmp-glibc/work/core2-64-nilrt-linux/pango/1.40.1-r0/build'

Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
---
 meta/recipes-graphics/pango/pango_1.40.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/pango/pango_1.40.1.bb b/meta/recipes-graphics/pango/pango_1.40.1.bb
index 60288a1..159f591 100644
--- a/meta/recipes-graphics/pango/pango_1.40.1.bb
+++ b/meta/recipes-graphics/pango/pango_1.40.1.bb
@@ -19,7 +19,7 @@ SRC_URI += "file://run-ptest \
 SRC_URI[archive.md5sum] = "6fc88c6529890d6c8e03074d57a3eceb"
 SRC_URI[archive.sha256sum] = "e27af54172c72b3ac6be53c9a4c67053e16c905e02addcf3a603ceb2005c1a40"
 
-DEPENDS = "glib-2.0 glib-2.0-native fontconfig freetype virtual/libiconv cairo harfbuzz"
+DEPENDS = "glib-2.0 glib-2.0-native fontconfig freetype virtual/libiconv cairo harfbuzz libpcre"
 
 PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
 PACKAGECONFIG[x11] = "--with-xft,--without-xft,virtual/libx11 libxft"
-- 
2.9.3

Re: [PATCH] pango: add libpcre to DEPENDS

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On 8 September 2016 at 10:56, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:

> | ./gen-all-unicode > all-unicode.txt
> | ./gen-all-unicode: error while loading shared libraries: libpcre.so.1:
> cannot open shared object file: No such file or directory
>

Can you replicate this on demand?  For gen-all-unicode to have been built
the library must have been in the sysroot, and removed by the time it was
executed.  However, pcre is a dependency of glib which is a dependency of
pango, so I'm not sure how this happened.

Ross

[-- Attachment #2: Type: text/html, Size: 950 bytes --]

Re: [PATCH] pango: add libpcre to DEPENDS

[Ioan-Adrian Ratiu]

On Thu, 08 Sep 2016, "Burton, Ross" <ross.burton@intel.com> wrote:
> On 8 September 2016 at 10:56, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:
>
>> | ./gen-all-unicode > all-unicode.txt
>> | ./gen-all-unicode: error while loading shared libraries: libpcre.so.1:
>> cannot open shared object file: No such file or directory
>>
>
> Can you replicate this on demand?  For gen-all-unicode to have been built
> the library must have been in the sysroot, and removed by the time it was
> executed.  However, pcre is a dependency of glib which is a dependency of
> pango, so I'm not sure how this happened.

No. It fails sporadically on the jenkins build machine when it's under
load. Somehow adding the pcre dependency directly to pango fixes the
build machine which is really weird. I can't replicate this on my dev
machine.

>
> Ross

Re: [PATCH] pango: add libpcre to DEPENDS

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On 8 September 2016 at 11:37, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:

> No. It fails sporadically on the jenkins build machine when it's under
> load. Somehow adding the pcre dependency directly to pango fixes the
> build machine which is really weird. I can't replicate this on my dev
> machine.
>

Can you get access to the build directory when it fails?  It would be
interesting to see what ldd says the gen-all-unicode is linking to.

Ross

[-- Attachment #2: Type: text/html, Size: 880 bytes --]

Re: [PATCH] pango: add libpcre to DEPENDS

[Ioan-Adrian Ratiu]

On Thu, 08 Sep 2016, "Burton, Ross" <ross.burton@intel.com> wrote:
> On 8 September 2016 at 11:37, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:
>
>> No. It fails sporadically on the jenkins build machine when it's under
>> load. Somehow adding the pcre dependency directly to pango fixes the
>> build machine which is really weird. I can't replicate this on my dev
>> machine.
>>
>
> Can you get access to the build directory when it fails?  It would be
> interesting to see what ldd says the gen-all-unicode is linking to.

I cleared the build directory and sstate cache, started with a clean
rebuild and I can't reproduce the error anymore. gen-all-unicode is
built as expected and at runtime it links with libpcre as expected
and the build succeeds. This is really weird, I didn't touch these
packages at all, they just sporadically failed out of the blue and now
they work.

>
> Ross

Re: [PATCH] pango: add libpcre to DEPENDS

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On 9 September 2016 at 10:32, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:

> I cleared the build directory and sstate cache, started with a clean
> rebuild and I can't reproduce the error anymore. gen-all-unicode is
> built as expected and at runtime it links with libpcre as expected
> and the build succeeds. This is really weird, I didn't touch these
> packages at all, they just sporadically failed out of the blue and now
> they work.
>

That's good, right? :)

If you ever manage to replicate, please save the build directory for
inspection.

Ross

[-- Attachment #2: Type: text/html, Size: 1062 bytes --]

Re: [PATCH] pango: add libpcre to DEPENDS

[Ioan-Adrian Ratiu]

Hi again

On Fri, 09 Sep 2016, "Burton, Ross" <ross.burton@intel.com> wrote:
> On 9 September 2016 at 10:32, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:
>
>> I cleared the build directory and sstate cache, started with a clean
>> rebuild and I can't reproduce the error anymore. gen-all-unicode is
>> built as expected and at runtime it links with libpcre as expected
>> and the build succeeds. This is really weird, I didn't touch these
>> packages at all, they just sporadically failed out of the blue and now
>> they work.
>>
>
> That's good, right? :)
>
> If you ever manage to replicate, please save the build directory for
> inspection.

I managed to replicate this and save the build directory to inspect it!

Here's what happens:
Besides oe-core we're using meta-selinux which has a libpcre-%.bbappend
which moves the location of libpcre.so from /usr/lib to /lib in the
sysroot and points the symlink to the file in /lib using relative paths.

ldd tests/gen-all-unicode gives this:

$ ldd tests/gen-all-unicode
	linux-vdso.so.1 (0x00007fff27263000)
	libglib-2.0.so.0 => /mnt/build/jenkins-jobs/nilrt_OE_toolchain-cardassia/workspace/build/tmp-glibc/sysroots/x86_64-linux/usr/lib/libglib-2.0.so.0 (0x00007f542823a000)
	libpcre.so.1 => not found
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f542801d000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5427c72000)
	libpcre.so.1 => /mnt/build/jenkins-jobs/nilrt_OE_toolchain/workspace/build/tmp-glibc/sysroots/x86_64-linux/usr/lib/../../lib/libpcre.so.1 (0x00007f5427a2f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5428546000)

I don't understand why libpcre.so.1 appears twice with the first not found.

The file pointed to by the libpcre.so.1 symlink exists but somehow the
loader can't find it? Maybe it's the ../.. in the path? or does an
variable like LD_LIBRARY_PATH need to be set in the bb recipe/append?

Ionel

>
> Ross

Re: [PATCH] pango: add libpcre to DEPENDS

[Ioan-Adrian Ratiu]

On Wed, 05 Oct 2016, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:
> Hi again
>
> On Fri, 09 Sep 2016, "Burton, Ross" <ross.burton@intel.com> wrote:
>> On 9 September 2016 at 10:32, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:
>>
>>> I cleared the build directory and sstate cache, started with a clean
>>> rebuild and I can't reproduce the error anymore. gen-all-unicode is
>>> built as expected and at runtime it links with libpcre as expected
>>> and the build succeeds. This is really weird, I didn't touch these
>>> packages at all, they just sporadically failed out of the blue and now
>>> they work.
>>>
>>
>> That's good, right? :)
>>
>> If you ever manage to replicate, please save the build directory for
>> inspection.
>
> I managed to replicate this and save the build directory to inspect it!
>
> Here's what happens:
> Besides oe-core we're using meta-selinux which has a libpcre-%.bbappend
> which moves the location of libpcre.so from /usr/lib to /lib in the
> sysroot and points the symlink to the file in /lib using relative paths.
>
> ldd tests/gen-all-unicode gives this:
>
> $ ldd tests/gen-all-unicode
> 	linux-vdso.so.1 (0x00007fff27263000)
> 	libglib-2.0.so.0 => /mnt/build/jenkins-jobs/nilrt_OE_toolchain-cardassia/workspace/build/tmp-glibc/sysroots/x86_64-linux/usr/lib/libglib-2.0.so.0 (0x00007f542823a000)
> 	libpcre.so.1 => not found
> 	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f542801d000)
> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5427c72000)
> 	libpcre.so.1 => /mnt/build/jenkins-jobs/nilrt_OE_toolchain/workspace/build/tmp-glibc/sysroots/x86_64-linux/usr/lib/../../lib/libpcre.so.1 (0x00007f5427a2f000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007f5428546000)
>
> I don't understand why libpcre.so.1 appears twice with the first not found.
>
> The file pointed to by the libpcre.so.1 symlink exists but somehow the
> loader can't find it? Maybe it's the ../.. in the path? or does an
> variable like LD_LIBRARY_PATH need to be set in the bb recipe/append?

I think libpcre_%.bbappend in meta-selinux is just missing the following
line:

ln -sf ${relpath}/${realsofile} ${D}${libdir}/libpcre.so.1

after creating this symlink the build works without problems (previously
only libpcre.so symlink was created).

Is this a proper solution?

>
> Ionel
>
>>
>> Ross
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] pango: add libpcre to DEPENDS

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

On 5 October 2016 at 12:59, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:

> I think libpcre_%.bbappend in meta-selinux is just missing the following
> line:
>
> ln -sf ${relpath}/${realsofile} ${D}${libdir}/libpcre.so.1
>
> after creating this symlink the build works without problems (previously
> only libpcre.so symlink was created).
>
> Is this a proper solution?
>

As meta-selinux is messing around with library locations, yes.

Ross

[-- Attachment #2: Type: text/html, Size: 879 bytes --]

Re: [PATCH] pango: add libpcre to DEPENDS

[Ioan-Adrian Ratiu]

On Wed, 05 Oct 2016, "Burton, Ross" <ross.burton@intel.com> wrote:
> On 5 October 2016 at 12:59, Ioan-Adrian Ratiu <adrian.ratiu@ni.com> wrote:
>
>> I think libpcre_%.bbappend in meta-selinux is just missing the following
>> line:
>>
>> ln -sf ${relpath}/${realsofile} ${D}${libdir}/libpcre.so.1
>>
>> after creating this symlink the build works without problems (previously
>> only libpcre.so symlink was created).
>>
>> Is this a proper solution?
>>
>
> As meta-selinux is messing around with library locations, yes.

This may be a stupid question (sorry) but here goes: Why can't ldconfig
be made to search also in /lib, beside /usr/lib? That way it could find
the moved libraries, right?

>
> Ross