From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1O3ms2-0008LS-Pz for garchives@archives.gentoo.org; Mon, 19 Apr 2010 09:02:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DBC88E0928 for ; Mon, 19 Apr 2010 09:02:16 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [134.93.178.246]) by pigeon.gentoo.org (Postfix) with ESMTP id 77EC1E0882 for ; Mon, 19 Apr 2010 08:52:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=cschwan@students.uni-mainz.de; q=dns/txt; s=ironport; t=1271667180; x=1303203180; h=from:to:subject:date:references:in-reply-to:mime-version: content-transfer-encoding:message-id; z=From:=20Christopher=20Schwan=20|To:=20|Subject: =20Re:=20[gentoo-science]=20sage-4.3.5-r1=20&&=20sage-cor e|Date:=20Mon,=2019=20Apr=202010=2010:52:54=20+0200 |References:=20<1271617825.14657.0@pavilion64>=20<2010041 82228.55704.cschwan@students.uni-mainz.de>=20<20100419151 8.22028.f.r.bissey@massey.ac.nz>|In-Reply-To:=20<20100419 1518.22028.f.r.bissey@massey.ac.nz>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Message-ID:=20<201004191052.54765.cschwan@students.uni-m ainz.de>; bh=4fKC1+0gyRofJWfO7FlI0RSKJaVoHBtrjiKUYU5q7LI=; b=NoXBzx6ePhU3QI6JvnnUV3aCcQuo5U0UASSYuxoWlI40iFc3Qhb0wk5C sQDDUoOYv8pWbDkx25K98qxz7CMZTesKUrKrVkyu4sNS6dsH0vTE2zwPt hc6NMcNMaZtWq0ppr9AMiehLkT6w/VQKFR8H3aqKMvQiz1QuVSWfsF5WJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFK2y0sKXgZY/2dsb2JhbACPe4xquX2FEAQ Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 19 Apr 2010 10:52:59 +0200 Received: from gnuke-notebook.localnet (134.93.86.71) by mail.uni-mainz.de (10.94.6.90) with Microsoft SMTP Server (TLS) id 14.1.135.1; Mon, 19 Apr 2010 10:52:58 +0200 From: Christopher Schwan To: Subject: Re: [gentoo-science] sage-4.3.5-r1 && sage-core Date: Mon, 19 Apr 2010 10:52:54 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.33-gentoo; KDE/4.4.2; i686; ; ) References: <1271617825.14657.0@pavilion64> <201004182228.55704.cschwan@students.uni-mainz.de> <201004191518.22028.f.r.bissey@massey.ac.nz> In-Reply-To: <201004191518.22028.f.r.bissey@massey.ac.nz> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <201004191052.54765.cschwan@students.uni-mainz.de> X-Archives-Salt: e9969fec-79e3-43d9-aa6c-ad83581a71dd X-Archives-Hash: 4ad817973f77f927b30cdee8cac6b67e On Monday 19 April 2010 05:18:21 Fran=E7ois Bissey wrote: > > Hi Steve, > >=20 > > On Sunday 18 April 2010 21:10:17 Steven Trogdon wrote: > > > Christopher, > > >=20 > > >=20 > > >=20 > > > I've finally gotten around to trying the changes and a clean emerge of > > > everything installs as it should. Here a revdep-rebuild reveals that > > > libsingular.so can't be found. The proposed resolution is to re-emerge > > > sage-core which, of course, doesn't resolve the issue. What's the > > > procedure to update the ld cache when libraries like libsingular.so a= re > > > not in the "standard" location? Should something be done in > > > sage-singular that doesn't compromise things? > >=20 > > I noticed the same behavior and looked at /etc/ld.so.cache which pointed > > to /etc/env.d/... - so the gentoo way of doing this would be to add a > > file which contains LDPATH=3D"/opt/sage/local/lib". Though I did not te= st > > it, it should work and I will add this file tomorrow. >=20 > Hi guys, >=20 > I don't like that solution at all. What will happen if you have system wi= de > singular and sage-singular? > If you add this file there is a good chance that someone wanting to use > the system provided singular will end up using sage-singular. Yes, thats right! - I did not think of that. >=20 > Just for the purpose of testing for side effects, I installed > singular-3.1.1. revdep-rebuild didn't pick up on sage-core after that. > Probably because libsingular lacks an soname and is completely > unversioned. >=20 > No. sage-env takes care of telling sage where to look. There is no real > perfect solution so long as we have ship sage-singular. > For now I would put a file in /etc/revdep-rebuild masking the offending > libraries. > 50sage-core: > #Those files look for a version of libsingular that will be located throu= gh > # LD_LIBRARY_PATH at run-time. > LD_LIBRARY_MASK=3D"lib1.so lib2.so lib3.so" Another option (read: hack) would be to create a separate directory contain= ing=20 a symlink to libsingular.so (this is the only library which is reported by= =20 revdep-rebuild) and to point revdep-rebuild to this directory. Of course, t= his=20 is not the best way of getting rid of this error. In my opinion, the best "solution" would be to print out a warning/info aft= er=20 installing sage-core which basically says revdep-rebuild reports false=20 positives and just wait for the Sage people upgrading to a new release of=20 Singular (see http://trac.sagemath.org/sage_trac/ticket/8059 and=20 http://trac.sagemath.org/sage_trac/ticket/8228). >=20 > ----- > Of course that means that revdep-rebuild cannot pick up the fact that > they are broken. Which of course it may not be able to do anyway because > of the lack of versioning. > On the positive side a change in sage-singular will always coincide with > a change of sage-core so there shouldn't be any trouble. >=20 > Francois Christopher