From owner-freebsd-current@FreeBSD.ORG Mon Nov 18 01:33:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C824CD0C for ; Mon, 18 Nov 2013 01:33:40 +0000 (UTC) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8628123D5 for ; Mon, 18 Nov 2013 01:33:40 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id ht10so515059vcb.29 for ; Sun, 17 Nov 2013 17:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=Oy2pfJyyNeBBkS6XZlgEuJMPX6zaziWS71BPZbb2lVg=; b=dw9qZ3OGr2C38r7fd96Dyeo/39tN+95kHLzRi1f/TEtJCZWhVVuyPVlbol07jCmWwF gy9wnCPG7fn0dm8TZnkSXyqoTIAadC/wPCXM0pzJvnbb2Mms5V2lbnw/z2awA3Bl/UVP Orv59gDMx7Cvj4T/UDkZ0QjGqCGixoZPGBbig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Oy2pfJyyNeBBkS6XZlgEuJMPX6zaziWS71BPZbb2lVg=; b=i1gGGhbZgT/3PhO0kA0l2NPU3eepl6Yt4XBtosm628h3tzThbUJb7sk4Y1Ma2u2XJQ tTCXAp4q01y/Ktk2coGATX15KFLaDAH7givxeLggXkZAedklkUBBe1HiAnFJHMkozQU+ +xzQE6xe2NdTQpa747vIIKNZLyXTwOeClf+ScCeBjApRx2bTXGP2uQ3nxcEiEQ2vR/BS jy90CT3yR+pK8dBtzdRnxx9wioBNKZBINg+yEc/z8QpM6dXrf04SrvpwNz2iYQyRvnNZ 1xgSv4cT/7TMNYTFK6OqC29sr0vP5YLnnZQAcWGq5mi7fpOIK172bVwFcC3BUEj2N3p/ OU0g== X-Gm-Message-State: ALoCoQnxxGttz98OKg64umBoctmELBhyI9IKd+vcdSDW8hRaypBI6nZkf2aB8Hx6nMAbVujUQGof MIME-Version: 1.0 X-Received: by 10.52.33.44 with SMTP id o12mr10910870vdi.7.1384738419620; Sun, 17 Nov 2013 17:33:39 -0800 (PST) Received: by 10.220.167.74 with HTTP; Sun, 17 Nov 2013 17:33:39 -0800 (PST) Date: Sun, 17 Nov 2013 17:33:39 -0800 Message-ID: Subject: Fwd: FYI: svn commit: r258283 - in head: . include lib lib/libc lib/libc/iconv lib/libc_nonshared From: Peter Wemm To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 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, 18 Nov 2013 01:33:40 -0000 FYI, for folks not following commit messages.. There is a potential new-binaries-on-old-systems gotcha here. If you compile an iconv-using program on a system *after* this commit and try to run the binary on an *old* pre-commit system, you will get undefined symbols. Going forwards is fine - a buildworld on an established system is safe. Old binaries run on new systems. Most folks would never hit this, except perhaps: * you build a bunch of iconv-using binaries in /usr/local, then revert your /usr/src to and old rev and buildworld. * you try and copy/install binary packages build on a new system onto an old system. New binaries on old systems generally isn't supported. Particularly so on -current. ---------- Forwarded message ---------- From: Peter Wemm Date: Sun, Nov 17, 2013 at 2:52 PM Subject: svn commit: r258283 - in head: . include lib lib/libc lib/libc/iconv lib/libc_nonshared To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: peter Date: Sun Nov 17 22:52:17 2013 New Revision: 258283 URL: http://svnweb.freebsd.org/changeset/base/258283 Log: Attempt to move the POSIX iconv* symbols out of runtime linker space. FreeBSD systems usually implemented this as a third party module and our implementation hasn't played as nicely with the old way as it could have. To that end: * Rename the iconv* symbols in libc.so.7 to have a __bsd_ prefix. * Provide .symver compatability with existing 10.x+ binaries that referenced the iconv symbols. All existing binaries should work. * Like on Linux/glibc systems, add a libc_nonshared.a to the ldscript at /usr/lib/libc.so. * Move the "iconv*" wrapper symbols to libc_nonshared.a This should solve the runtime ambiguity about which symbols resolve to where. If you compile against the iconv in libc, your runtime dependencies will be unambiguous. Old 9.x libraries and binaries will always resolve against their libiconv.so.3 like they did on 9.x. They won't resolve against libc. Old 10.x binaries will be satisified by the .symver helpers. This should allow ports to selectively compile against the libiconv port if needed and it should behave without ambiguity now. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV