From owner-freebsd-current@FreeBSD.ORG Mon Oct 28 22:15:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BDE3875F for ; Mon, 28 Oct 2013 22:15:00 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id E460B23CF4D for ; Mon, 28 Oct 2013 23:14:58 +0100 (CET) Message-ID: <526EE1E2.5070201@FreeBSD.org> Date: Mon, 28 Oct 2013 23:14:58 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: latest sbin/pkg updates seem to break HEAD References: <526B9FC7.2040005@gwdg.de> <526BA1AB.4060806@gmx.de> <526BB8C9.4@gwdg.de> In-Reply-To: <526BB8C9.4@gwdg.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 22:15:01 -0000 Am 26.10.2013 14:42, schrieb Rainer Hurling: > Am 26.10.2013 13:04, schrieb Matthias Andree: >> Am 26.10.2013 12:56, schrieb Rainer Hurling: >>> After svn update my 11.0-CURRENT box to r257152, the build breaks. >>> Obviously there is something wrong with the newest patches for sbin/pkg >>> (or libcrypt). Am I the only one observing this? >>> >>> Any help is appreciated, >>> Rainer Hurling >>> >>> >>> [..snip..] >>> ===> usr.sbin/pkg (all) >> ... >>> cc -O2 -pipe -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include -std=gnu99 >>> [...] >>> -L/usr/obj/usr/src/tmp/usr/lib/private -rpath /usr/lib/private -o pkg >>> pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lyaml -lsbuf -lssl >>> >>> /usr/obj/usr/src/tmp/usr/bin/ld: D: invalid DSO for symbol `EVP_PKEY_free' definition This means that the indirect dependency pulled in from one of the given libraries (-lssl in this case) is not eligible for resolving EVP_PKEY_free(), because the library that provides this EVP_PKEY_free() is not mentioned explicitly on the linker's command line. >>> /usr/obj/usr/src/tmp/lib/libcrypto.so.7: could not read symbols: Bad value ...and this line translates to "libcrypto.so.7: was brought in as indirect dependency, could resolve your missing symbol, but is not permitted to. Add -lcrypto explicitly to the linker command line." Arguably Fedora Linux offers nicer error messages if the screenshot (URL/quote below) is authentic. >>> cc: error: linker command failed with exit code 1 (use -v to see invocation) >>> *** Error code 1 >>> Stop. >>> make[4]: stopped in /usr/src/usr.sbin/pkg >> >> These can happen if a library is missing, for instance, -lcrypto is >> apparently not mentioned on the linker's command line, but AFAIR the >> clang linker accepts no unresolved symbols from .so when linking >> executables, and -lssl likely needs -lcrypto. This avoids run-time >> surprises due to missing dependencies (on libcrypto, in this case). >> >> Try pasting that command line with -lcrypto added after -lssl, and if >> that helps, try to debug where the -lcrypto has been or gets lost, or >> should get added. >> >> HTH > > Yep, adding -lcrypto seems to help. I patched usr.sbin/pkg/Makefile for it. > > But I am wondering if nobody else has this problem? I did not change my > systems sources before. Greetings, I discussed this a bit with Bryan Drewery on IRC, and the information pieces that I will post here for posterity and to have this in the archives are: 1. pkg itself calls the EVP_*() functions from libcrypto. 2. on bdrewery's system, the linker pulled libcrypto in through libssl as an indirect dependency. It was not supposed to do that, but happened - as to why, we don't know. 3. The general idea, that bdrewery agrees to, is that all shared dependencies must be specified directly on the linker's command line. this has the screenshot with a nicer error message: > /usr/bin/ld.bfd: rpmdumpheader.o: undefined reference to symbol 'Fopen' > /usr/bin/ld.bfd: note: 'Fopen' is defined in DSO /usr/lib/librpmio.so.0 so try adding it to the linker command line > /usr/lib/librpmio.so.0: could not read symbols: Invalid operation 4. It's not necessarily clang that causes it, but either gold, or a change to FreeBSD's ld in Late July that disabled the use of indirect dependencies . Hope that helps. Best regards Matthias