From owner-freebsd-x11@FreeBSD.ORG Tue Jul 5 21:11:20 2011 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F2EF1065673; Tue, 5 Jul 2011 21:11:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D0BD38FC12; Tue, 5 Jul 2011 21:11:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p65LBFNv042790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jul 2011 00:11:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p65LBFWO064944; Wed, 6 Jul 2011 00:11:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p65LBE4l064943; Wed, 6 Jul 2011 00:11:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 6 Jul 2011 00:11:14 +0300 From: Kostik Belousov To: bf1783@gmail.com Message-ID: <20110705211114.GJ48734@deviant.kiev.zoral.com.ua> References: <4E0FCDD1.7050809@missouri.edu> <4E0FD8DC.20700@missouri.edu> <20110703114104.GK48734@deviant.kiev.zoral.com.ua> <20110703140400.GO48734@deviant.kiev.zoral.com.ua> <20110705095600.GE48734@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U0lwbJGzT0Gq35lP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "freebsd-x11@FreeBSD.org" , danfe@freebsd.org Subject: Re: x11/nvidia-driver incompatible with portmaster? X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 21:11:20 -0000 --U0lwbJGzT0Gq35lP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 05, 2011 at 08:32:51AM -0400, b. f. wrote: > On 7/5/11, Kostik Belousov wrote: > > On Tue, Jul 05, 2011 at 05:58:53AM +0000, b. f. wrote: > >> On 7/3/11, Kostik Belousov wrote: > >> > On Sun, Jul 03, 2011 at 12:45:50PM +0000, b. f. wrote: > >> >> On 7/3/11, Kostik Belousov wrote: > >> >> > On Sun, Jul 03, 2011 at 03:54:15AM +0000, b. f. wrote: > >> >> >> On 7/3/11, Stephen Montgomery-Smith wrote: > >> >> >> > On 07/02/2011 09:02 PM, Stephen Montgomery-Smith wrote: > >> >> >> >> On 07/02/2011 08:39 PM, b. f. wrote: > >> >> ... > >> >> > > >> >> > That said, there is absolutely no need in any static linker trick= s, > >> >> > esp. a heavy one like filters or linker scripts. A symlink named > >> ... > >> >> > >> >> > libGL.so would be enough for the static linker, pointing to any > >> >> > of two libraries. And symlink libGL.so.1 would be also enough > >> >> > for dynamic linker. > >> >> > > >> >> > The real issue with xorg-server, mesa and nvidia driver is only > >> >> > the overwrite of extensions/libglx.so and lib/libGL.so.1. If > >> >> > this can be somewhat solved by the packaging system, that would > >> >> > be great. On my hybrid laptop I have to manually manage the > >> >> > said symlinks (actually, with the rc script that verifies > >> >> > the list of pci devices and arranges the symlinks). > >> >> > >> >> So basically, you would prefer that we: > >> >> > >> >> patch xorg-server so that it installs, e.g., > >> >> ${PREFIX}/lib/xorg/modules/extensions/libglx-xorg.so.1 instead of > >> >> ${PREFIX}/lib/xorg/modules/extensions/libglx.so.1, and points the > >> >> symlink ${PREFIX}/lib/xorg/modules/extensions/libglx-xorg.so at the > >> >> former; > >> >> > >> >> patch libGL so that it installs, e.g., ${PREFIX}/lib/libGL-mesa.so.1 > >> >> instead of ${PREFIX}/lib/libGL.so.1, and points the symlink > >> >> ${PREFIX}/lib/libGL.so at the former; > >> >> > >> >> and patch nvidia-driver so that it installs, e.g., > >> >> ${PREFIX}/lib/xorg/modules/extensions/libglx-nvidia.so.1 instead of > >> >> ${PREFIX}/lib/xorg/modules/extensions/libglx.so.1, and > >> >> ${PREFIX}/lib/libGL-nvidia.so.1 instead of ${PREFIX}/lib/libGL.so.1; > >> >> and during installation it overwrites the > >> >> ${PREFIX}/lib/xorg/modules/extensions/libglx-xorg.so and > >> >> ${PREFIX}/lib/libGL.so symlinks, redirecting them to the correspond= ing > >> >> nvidia libraries; while during deinstallation it changes them to po= int > >> >> to the mesa/xorg libraries? > >> > Yes. > >> > > >> >> > >> >> And corresponding redirection to handle the libtool archive file? > >> > I do not think this is needed. First, I believe .la files are only > >> > installed by the Xorg ports. Second, as I described, libGL.so from > >> > Xorg and from NVidia should be replacable for the static linking > >> > purposes. Third, libglx.la is not used at all. > >> ... > >> > On Sun, Jul 03, 2011 at 01:33:09PM +0000, b. f. wrote: > >> >> On second thought the renaming of these libraries is not very > >> >> convenient, since they are built by nvidia, and not necessary if th= eir > >> >> mesa/xorg counterparts already have different names. > >> > > >> > As I said, it is useful for me on the hybrid laptop, where a switch > >> > selects the GPU attached to the panel. The startup script then would > >> > only need to create proper symlink, instead of delicate renaming > >> > of the libraries. > >> > >> Please consider the attached patch. Small unrelated clean-ups to > >> x11-servers/xorg-server and bsd.mesalib.mk are included with the > >> changes that remove the collisions, and add the necessary symlinks. > >> The renaming in the xorg-server post-install target is a bit ugly, but > >> much easier than dissecting the libtool build and installation of the > >> glx convenience library. I used sed rather than patches for some of > >> the changes in libGL and nvidia-driver because of the multiple > >> distfiles involved. > >> > > > > I think that the policy in xorg and mesa ports should be to install > > symlinks if they are not present, instead of checking for the > > presence of nvidia driver. >=20 > Can do -- although it raises the small possibility that the link could > be damaged or left dangling and forgotten, and interfere with > subsequent reinstallation. That's not a problem for someone like you, > but other users may not be able to fix such a problem as easily.) But > on removal, what then? Always remove the symlink? Always leave it in > place? Or try to determine whether it points to a library owned by the > port being removed, and remove it if it does? I don't think the > second would be a good idea for many users. Ok. >=20 > > > > Also, the installation of libglx.so and post-factum renaming looks rude > > and could probably cause complications since original libglx.so symlink > > is removed, am I right ? > > >=20 > Yes, as I wrote, I wasn't altogether happy with that, but it was > expedient. If there is a symlink there, it will be overwritten, and > then replaced by a link to either the xorg library or the > nvidia-driver library, depending upon whether the nvidia-driver is > present. Of course, that's not so different from any other port > installation, which will overwrite existing files and links. But I > guess you're using some alternative symlinks that you want to > preserve? I could take the low road, and move the link out of the way > temporarily, restoring it after renaming the xorg library, or I could > take the high road and add further patches to override the current > libtool install. Which road is it to be? I cannot judge the implementation, but the supposed behaviour should be a step forward for paceful coexistence of Xorg server, Mesa and NVidia driver. --U0lwbJGzT0Gq35lP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4TffIACgkQC3+MBN1Mb4hbjgCfd5XW267RpjEvhAhBlN7KH5Oe BuMAoLJRCq8mD8wn8BelUdJiyaW5D578 =8H47 -----END PGP SIGNATURE----- --U0lwbJGzT0Gq35lP--