From owner-freebsd-toolchain@freebsd.org Mon May 16 04:24:34 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFD77B3CDB5 for ; Mon, 16 May 2016 04:24:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-168.reflexion.net [208.70.211.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 956B41D16 for ; Mon, 16 May 2016 04:24:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1839 invoked from network); 16 May 2016 04:17:49 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 16 May 2016 04:17:49 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 16 May 2016 00:17:51 -0400 (EDT) Received: (qmail 32053 invoked from network); 16 May 2016 04:17:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 16 May 2016 04:17:51 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.106] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 4A34DB1E001; Sun, 15 May 2016 21:17:46 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT problems with LD_LIBRARY_PATH? building perl 5.22 from source example Date: Sun, 15 May 2016 21:17:51 -0700 Message-Id: Cc: freebsd-arm , FreeBSD PowerPC ML , mat@FreeBSD.org, FreeBSD Current To: FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 04:24:34 -0000 [This is associated with = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209173 against = lang/perl5.22 (and implicitly some other lang/perl5.* examples) .] Problem: building lang/perl5.22 from source (say via portmaster) with no = prior perl5.22 installed leads to: > Shared object "libperl.so.5.22" not found, required by "perl" on 11.0-CURRENT. (I've not tried a 10.x context so far. As stands I do = not have one.) I'll first give some operational context and then show some readelf = output and truss output that suggests some about what is or is not going = on. Then I'll give some other supporting details. Operational Context. . . The perl port tries to build the perl executable and test it before = anything new has been installed in: > /usr/local/lib/perl5/5.22/mach/CORE (This is before staging. Note: I happen to be using use "portmaster -DK = lang/perl5.22" to build so materials are left behind from build = failures. Paths below are from my particular context.) But it also builds the perl executable based on using: > -Wl,-R/usr/local/lib/perl5/5.22/mach/CORE leaving only something like LD_LIBRARY_PATH as a means of picking up the = new libperl.so.5.22 during any pre-final-installation tests of the perl = executable built. And perl's build sequence does do such tests, = including checking that the version number matches what it should. = (libperl.so is where the version number comes from.) My initial example here will be for no pre-existing perl5.22 = installation. I will note a little about if, say, perl5.22.1 has been = successfully installed first before an update to perl5.22.2. Getting to = that point for 5.22.1 may require a work around. Using portmaster to build perl 5.22 (specifically here 5.22.2) gets to = the point of testing > /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/perl which fails. Without a prior build of perl5.22 it fails with: > Shared object "libperl.so.5.22" not found, required by "perl" If there is instead an older 5.22.1 for an update to 5.22.2 the failure = is for finding and using the older libperl.so.5.22 which returns the = older version number, something perl's build procedure checks. If after the failure I copy the libperl.so* files from: > /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/ to: > /usr/local/lib/perl5/5.22/mach/CORE/ and then try "portmaster -DK lang/perl5.22" again the build works based = on finding the new libperl.so.5.22 in the place it was not present = before (no file or older vintage file). So what is going on?. . . Below is readelf and truss output related to seeing what is or is not = going on. . . (My example here happens to be on a 11.0 based rpi2 armv6 build but in = my case tailored to cortex-a7/armv7.) > # readelf --dynamic = /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/perl | grep = PATH > 0x0000000f RPATH Library rpath: = [/usr/local/lib/perl5/5.22/mach/CORE] > 0x0000001d RUNPATH Library runpath: = [/usr/local/lib/perl5/5.22/mach/CORE] > # env = LD_LIBRARY_PATH=3D/usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.2= 2.2 truss = /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/perl > mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,21,0x1000) =3D = 537092096 (0x20036000) > issetugid() =3D 0 (0x0) > stat("/usr/libsoft",{ mode=3Ddrwxr-xr-x = ,inode=3D3698147,size=3D15360,blksize=3D32768 }) =3D 0 (0x0) > __sysctl(0xbfbfe68c,0x2,0x20035258,0xbfbfe688,0x1,0x0) =3D 0 (0x0) > __sysctl(0xbfbfe68c,0x2,0x20035358,0xbfbfe688,0x0,0x0) =3D 0 (0x0) > __sysctl(0xbfbfe68c,0x2,0x20035458,0xbfbfe688,0x0,0x0) =3D 0 (0x0) > __sysctl(0xbfbfe68c,0x2,0x20035558,0xbfbfe688,0x0,0x0) =3D 0 (0x0) > __sysctl(0xbfbfe68c,0x2,0x20035658,0xbfbfe688,0x0,0x0) =3D 0 (0x0) > lstat("/etc",{ mode=3Ddrwxr-xr-x = ,inode=3D40850304,size=3D2560,blksize=3D32768 }) =3D 0 (0x0) > lstat("/etc/libmap-soft.conf",0xbfbfe5a0) ERR#2 'No such file = or directory' > access("/usr/local/lib/perl5/5.22/mach/CORE/libthr.so.3",F_OK) ERR#2 = 'No such file or directory' > openat(AT_FDCWD,"/var/run/ld-elf-soft.so.hints",O_CLOEXEC,00) =3D 3 = (0x3) > read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\r\0\0\0"...,128) =3D 128 (0x80) > lseek(3,0x8000000000,SEEK_SET) =3D 128 (0x80) > read(3,"/usr/libsoft\0",13) =3D 13 (0xd) > close(3) =3D 0 (0x0) > access("/usr/libsoft/libthr.so.3",F_OK) =3D 0 (0x0) > openat(AT_FDCWD,"/usr/libsoft/libthr.so.3",O_CLOEXEC|O_VERIFY,00) =3D = 3 (0x3) > fstat(3,{ mode=3D-r--r--r-- ,inode=3D3692264,size=3D110496,blksize=3D327= 68 }) =3D 0 (0x0) > = mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,12,0xbfbfe0182002a66= 4) =3D 537055232 (0x2002d000) > = mmap(0x0,176128,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,537055316,0x3200= 2d074) =3D 537124864 (0x2003e000) > = mmap(0x2003e000,106496,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCOR= E|MAP_PREFAULT_READ,537055316,0x32002d074) =3D 537124864 (0x2003e000) > = mmap(0x2005f000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAU= LT_READ,537055316,0x32002d074) =3D 537260032 (0x2005f000) > = mmap(0x20060000,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,= 537055316,0x32002d074) =3D 537264128 (0x20060000) > munmap(0x2002d000,4096) =3D 0 (0x0) > close(3) =3D 0 (0x0) > access("/usr/local/lib/perl5/5.22/mach/CORE/libperl.so.5.22",F_OK) = ERR#2 'No such file or directory' > access("/usr/libsoft/libperl.so.5.22",F_OK) ERR#2 'No such file = or directory' > access("/usr/libsoft/libperl.so.5.22",F_OK) ERR#2 'No such file = or directory' > Shared object "libperl.so.5.22" not found, required by = "perl"write(2,"Shared object "libperl.so.5.22" "...,61) =3D 61 (0x3d) > =20 > write(2,"\n",1) =3D 1 (0x1) > exit(0x1) =20 > process exit, rval =3D 1 There is no evidence above of any attempt to use the path from "env = LD_LIBRARY_PATH=3D. . ." to access any file, much less libperl.so.5.22 = specifically. It is also interesting that the line > access("/usr/libsoft/libperl.so.5.22",F_OK) ERR#2 'No such file = or directory' repeats twice back-to-back. OTHER DETAILS. . . Mathieu Arnold has tried to make changes to the lang/perl5.22 materials = to help but so far the behavior is invariant to his changes. (He also = touched some other lang/perl5.* materials but I've been using just = 5.22.) My /usr/ports/ is at -r414889 and currently has a lang/perl5.22/Makefile = patch Mathieu had me try but the behavior in question did not change = from before I had no patch. My 11.0-CURRENT is at -r298990 (a no-debug build, 1100106 for kernel and = user). The build is tailored to the rpi2's cortex-a7/armv7 in world as = well as the kernel. I've previously attempted lang/perl5.22 upgrade-to-5.22.2 builds on = powerpc64 and powerpc but I'm away from those machines now and they are = unplugged, so no access currently. But what I'd done shows that the = problem is not specific to arm. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue May 17 18:04:30 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2ABBCB3F4CF for ; Tue, 17 May 2016 18:04:30 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 178E710D4 for ; Tue, 17 May 2016 18:04:30 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: by mailman.ysv.freebsd.org (Postfix) id 1316AB3F4CE; Tue, 17 May 2016 18:04:30 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12BE3B3F4CD for ; Tue, 17 May 2016 18:04:30 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D51F410D2; Tue, 17 May 2016 18:04:26 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 6758315340A; Tue, 17 May 2016 20:04:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwuU0vaXGllF; Tue, 17 May 2016 19:59:16 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:8c49:9de7:acf1:6a1f] (unknown [IPv6:2001:4cb8:3:1:8c49:9de7:acf1:6a1f]) by smtp.digiware.nl (Postfix) with ESMTP id E0C051534CF; Tue, 17 May 2016 19:59:16 +0200 (CEST) To: dim@freeBSD.org, toolchain@freebsd.org From: Willem Jan Withagen Subject: An error That seems to elude me in compiling Ceph Organization: Digiware Management b.v. Message-ID: <089bad88-d480-0ee3-7c88-4d0f1a0a92cb@digiware.nl> Date: Tue, 17 May 2016 19:59:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:04:30 -0000 Hi, I got this snippet of code that bombs out during linking.... if is from https://github.com/ceph/ceph/blob/master/src/rgw/rgw_file.h#L805 /* find or create an RGWFileHandle */ LookupFHResult lookup_fh(RGWFileHandle* parent, const char *name, const uint32_t flags = RGWFileHandle::FLAG_NONE) { using std::get; // This seems like a Clang compiler error. // It result in irgw::RGWFileHandle::FLAG_NONE being undefined during linking. // LookupFHResult fhr { nullptr, RGWFileHandle::FLAG_NONE }; LookupFHResult fhr { nullptr, 0 }; And the complaint in the end during linking that rgw:RGWFileHandle::FLAG_NONE is unknown. But as far as I know it is defined on line 255 in the same file. And even stranger.... 2 lines back there is also a reference to that same variable. Now the only modification I have to do is replace RGWFileHandle::FLAG_NONE on that last line of the snippet to get things going again. And note that references to the other defined vars around line 255 do not suffer from the same problem. Can anybody explain to me what I'm missing? Thanx, --WjW