From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ni.com (skprod3.natinst.com [130.164.80.24]) by mail.openembedded.org (Postfix) with ESMTP id 8A74971A0B for ; Wed, 5 Oct 2016 10:47:54 +0000 (UTC) Received: from us-aus-mgwout2.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod3.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id u95Alrj9024059; Wed, 5 Oct 2016 05:47:53 -0500 Received: from adi-pc-linux ([130.164.14.198]) by us-aus-mgwout2.amer.corp.natinst.com (Lotus Domino Release 8.5.3FP6 HF1218) with ESMTP id 2016100505475284-614248 ; Wed, 5 Oct 2016 05:47:52 -0500 From: Ioan-Adrian Ratiu To: "Burton\, Ross" In-Reply-To: References: <20160908095633.26651-1-adrian.ratiu@ni.com> <878tv2znhb.fsf@ni.com> <871t0tzads.fsf@ni.com> Date: Wed, 05 Oct 2016 13:46:02 +0300 Message-ID: <87bmyzdqfp.fsf@ni.com> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 10/05/2016 05:47:53 AM, Serialize by Router on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 10/05/2016 05:47:53 AM, Serialize complete at 10/05/2016 05:47:53 AM X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-05_04:, , signatures=0 Cc: OE-core Subject: Re: [PATCH] pango: add libpcre to DEPENDS X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 10:47:55 -0000 Content-Type: text/plain Hi again On Fri, 09 Sep 2016, "Burton, Ross" wrote: > On 9 September 2016 at 10:32, Ioan-Adrian Ratiu 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