From owner-freebsd-multimedia@FreeBSD.ORG Tue Nov 25 15:59:26 2014 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70A9EBB6; Tue, 25 Nov 2014 15:59:26 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0117.outbound.protection.outlook.com [157.56.110.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94CBCDD0; Tue, 25 Nov 2014 15:59:25 +0000 (UTC) Received: from [10.0.0.21] (73.5.142.244) by BY1PR0301MB0837.namprd03.prod.outlook.com (25.160.193.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 25 Nov 2014 15:43:18 +0000 Message-ID: <5474A38E.9000400@my.hennepintech.edu> Date: Tue, 25 Nov 2014 09:43:10 -0600 From: Andrew Berg User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Gary Palmer Subject: Re: [SOLVED] multimedia/x264 build failure, linker error References: <2002873.iA6NuqLZfy@amd.asgard.uk> <2718486.HeFL0Qyace@amd.asgard.uk> <24936541.dtFOE5QvMi@amd.asgard.uk> <20141124223344.GA9356@pcjas.obspm.fr> <20141125142631.GA24514@in-addr.com> <547493A0.70001@my.hennepintech.edu> <20141125145628.GB24514@in-addr.com> In-Reply-To: <20141125145628.GB24514@in-addr.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [73.5.142.244] X-ClientProxiedBy: BL2PR08CA0053.namprd08.prod.outlook.com (10.255.170.171) To BY1PR0301MB0837.namprd03.prod.outlook.com (25.160.193.143) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0837; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0837; X-Forefront-PRVS: 040655413E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(189002)(51704005)(24454002)(450100001)(77096003)(87976001)(31966008)(86362001)(92726001)(46102003)(77156002)(62966003)(50466002)(40100003)(4396001)(92566001)(42186005)(83506001)(21056001)(107046002)(89122001)(80316001)(95666004)(106356001)(105586002)(122386002)(65816999)(75432002)(50986999)(87266999)(54356999)(76176999)(93886004)(99396003)(59896002)(33656002)(101416001)(102836001)(110136001)(65806001)(88552001)(23676002)(65956001)(66066001)(120916001)(47776003)(20776003)(97736003)(64706001)(89472002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0837; H:[10.0.0.21]; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0837; X-OriginatorOrg: my.hennepintech.edu Cc: freebsd-multimedia@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:59:26 -0000 On 2014.11.25 08:56, Gary Palmer wrote: > On Tue, Nov 25, 2014 at 08:35:12AM -0600, Andrew Berg wrote: >> On 2014.11.25 08:26, Gary Palmer wrote: >> > Since I assume most of the packages that depend on the old x264-0.136.2358_4 >> > depend on the library rather than the CLI command, is there any harm in >> > doing >> > >> > portmaster -o multimedia/libx264 x264-0.136.2358_4 >> > >> > instead? That way the dependancies are kept (mostly) correct >> Don't do that. The dependency change has been properly handled, and those ports >> know to use multimedia/libx264. > > If you followed the instructions in the mail I replied to, the installed > packages are left with a dependency on x264 and not libx264. > > The real problem is that the few times I tried to use automated update > methods ran into problems because x264 was already installed and libx264 > couldn't be installed because they conflicted. Nothing seems to be > in UPDATING or MOVED so the upgrades break. There needs to be a better > way of handling these cases. As I have stated already in this thread, I am trying to get an UPDATING entry committed: x264 was split into the application and its library. If an application that uses libx264 is updated before x264 itself, multimedia/libx264 will conflict with the old x264 package. Delete the existing x264: # pkg delete x264 And then install the updated x264 and/or upgrade the other applications that depend on libx264. This is my fault for not testing upgrades via ports when creating the patch.