From patchwork Sat Nov 29 06:04:29 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 415952 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id E7FCD1401AD for ; Sat, 29 Nov 2014 17:04:44 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :content-type:content-transfer-encoding; q=dns; s=default; b=Sk0 oFC9+aVkVLGInJqqmVVCJYs1kMI1ArYndREcpYFEgpv18HEXH83DTFNKq3/XSOY+ mNY3+IPy5kI9a9GftN6LfXCEEpP5dxSl6x3jH5iTwERe0bqD2UTIHHm9Jt86Wax/ R9TUXsGZIfxwfMOjH7NtOR3VuUtZ9PLM3oaCyTbA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :content-type:content-transfer-encoding; s=default; bh=qJJtNL7/S hApkyMK+HyOoX95z4g=; b=MqEWeUtEQxbYOK2lqVl8ZlDzJ8Y8TOHW2p5Czv4eC gt2FESteGy6naaS45flVyh5t6zqY2CLdcNbLZMHvCB2X1Oso2Ui4Cl/ckKuBayEx SSSUX+yBNlZclqBYGJO0gFmynG8YcyVoPlV7Cu/ErKDAHqHzI1JOUGHqfRkNI4K1 Lc= Received: (qmail 23449 invoked by alias); 29 Nov 2014 06:04:38 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 23437 invoked by uid 89); 29 Nov 2014 06:04:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Message-ID: <547961ED.2040503@redhat.com> Date: Sat, 29 Nov 2014 01:04:29 -0500 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: GNU C Library Subject: [COMMITTED] elf/ldconfig.c: Expand comment in search_dir. Developers should be careful to make sure their development libraries always point to the SONAME file and not the arbitrary package name or ldconfig may create the wrong set of links. After working this out for some Red Hat packages I decided to add more comments to search_dir. The comments should be self explanatory and are exactly what ldconfig does. I have yet to talk about the badness that happens if you say copy ld.so to ld.so.bak and ld.so.bak is not u+x, perhaps I'll either fix that (by preventing symlinks to non-u+x files or documenting it in more comments). 2014-11-29 Carlos O'Donell * elf/ldconfig.c (search_dir): Expand comment. --- Cheers, Carlos. --- a/elf/ldconfig.c +++ b/elf/ldconfig.c @@ -893,8 +893,30 @@ search_dir (const struct dir_entry *entry) /* A link may just point to itself. */ if (is_link) { - /* If the path the link points to isn't its soname and it is not - .so symlink for ld(1) only, we treat it as a normal file. */ + /* If the path the link points to isn't its soname or it is not + the .so symlink for ld(1), we treat it as a normal file. + + You should always do this: + + libfoo.so -> SONAME -> Arbitrary package-chosen name. + + e.g. libfoo.so -> libfoo.so.1 -> libfooimp.so.9.99. + Given a SONAME of libfoo.so.1. + + You should *never* do this: + + libfoo.so -> libfooimp.so.9.99 + + If you do, and your SONAME is libfoo.so.1, then libfoo.so + fails to point at the SONAME. In that case ldconfig may consider + libfoo.so as another implementation of SONAME and will create + symlinks against it causing problems when you try to upgrade + or downgrade. The problems will arise because ldconfig will, + depending on directory ordering, creat symlinks against libfoo.so + e.g. libfoo.so.1.2 -> libfoo.so, but when libfoo.so is removed + (typically by the removal of a development pacakge not required + for the runtime) it will break the libfoo.so.1.2 symlink and the + application will fail to start. */ const char *real_base_name = basename (real_file_name); if (strcmp (real_base_name, soname) != 0)