From owner-freebsd-x11@FreeBSD.ORG Tue Jul 5 12:32:53 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 5CBD0106566B; Tue, 5 Jul 2011 12:32:53 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 296348FC13; Tue, 5 Jul 2011 12:32:52 +0000 (UTC) Received: by pzk27 with SMTP id 27so4065274pzk.13 for ; Tue, 05 Jul 2011 05:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3uz+l7o4l/JN8wiFzLF44jQotu48Q3NxmA+tv/mD43s=; b=B0BlP2GtXrCFLrcaDd0zCC27TWTlU2WTh4my6YUE6TxmFlAMbd0QjC6QueWpU9PN4I RgldlFRkoCsFZBTaYNyPnE+hMQKkxnjLGR0QdsJLenMA9zLFVYhKgso6hUciOw3eC1Gq jrIaiZEHDOVoGMe3ZLbTLI6+dFvL52qzLoaQg= MIME-Version: 1.0 Received: by 10.68.66.66 with SMTP id d2mr646038pbt.223.1309869172362; Tue, 05 Jul 2011 05:32:52 -0700 (PDT) Received: by 10.68.64.104 with HTTP; Tue, 5 Jul 2011 05:32:51 -0700 (PDT) In-Reply-To: <20110705095600.GE48734@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> Date: Tue, 5 Jul 2011 08:32:51 -0400 Message-ID: From: "b. f." To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 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 Reply-To: bf1783@gmail.com 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 12:32:53 -0000 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 tricks, >> >> > 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 corresponding >> >> nvidia libraries; while during deinstallation it changes them to point >> >> 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 their >> >> 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. 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. > > 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 ? > 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? b.