From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 59F54138247 for ; Mon, 13 Jan 2014 23:41:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 13762E0B9B; Mon, 13 Jan 2014 23:41:37 +0000 (UTC) Received: from mailfilter2.tranzpeer.net (mailfilter-228.tranzpeer.net [202.180.66.228]) by pigeon.gentoo.org (Postfix) with ESMTP id 5AD76E0B09 for ; Mon, 13 Jan 2014 23:41:36 +0000 (UTC) Received: from webmail.slingshot.co.nz (webmailfe2.prv.callplus.co.nz [202.189.160.42]) by mailfilter2.tranzpeer.net (Postfix) with ESMTP id 1B5687774 for ; Tue, 14 Jan 2014 12:41:35 +1300 (NZDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-science@lists.gentoo.org Reply-to: gentoo-science@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 14 Jan 2014 12:41:35 +1300 From: =?UTF-8?Q?Fran=C3=A7ois_Bissey?= To: gentoo-science@lists.gentoo.org Subject: Re: [gentoo-science] Build of cxvopt against acml not working In-Reply-To: <52D476FD.7070701@arcor.de> References: <52D46D28.6070707@arcor.de> <52D46D66.10809@arcor.de> <0c2a23e0b071c1041547c980f278478b@slingshot.co.nz> <52D472F3.9010702@arcor.de> <99b004ccd849bf9a0a7606acb1fa8e32@slingshot.co.nz> <52D476FD.7070701@arcor.de> Message-ID: <895cda57da0f9e93a26beba955428931@slingshot.co.nz> X-Sender: fbissey@slingshot.co.nz User-Agent: Roundcube Webmail/0.9.2 X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,KHOP_THREADED, LOCAL_SLINGSHOT_TEST,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spamsrv2 X-Archives-Salt: ccd31cdb-9529-475b-95f4-935852f183be X-Archives-Hash: 4cfb244187c3c110ee5690c87d24d317 On 2014-01-14 12:30, Bastian Löffler wrote: > No it does not work .... Do I have to do something after removing the > link? > OK I checked the ebuild. This is a bug I think because the prepare phase doesn't deal with the case where the library is not located under ${EPREFIX}/usr/lib{64}, I am guessing mkl must have the same problem. Thinking about a solution right now. Francois