x11/nvidia-driver incompatible with portmaster?

[Kostik Belousov]

On Tue, Jul 05, 2011 at 08:32:51AM -0400, b. f. wrote:
> On 7/5/11, Kostik Belousov <kostikbel at gmail.com> wrote:
> > On Tue, Jul 05, 2011 at 05:58:53AM +0000, b. f. wrote:
> >> On 7/3/11, Kostik Belousov <kostikbel at gmail.com> wrote:
> >> > On Sun, Jul 03, 2011 at 12:45:50PM +0000, b. f. wrote:
> >> >> On 7/3/11, Kostik Belousov <kostikbel at gmail.com> wrote:
> >> >> > On Sun, Jul 03, 2011 at 03:54:15AM +0000, b. f. wrote:
> >> >> >> On 7/3/11, Stephen Montgomery-Smith <stephen at missouri.edu> 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.
Ok.

> 
> >
> > 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?

I cannot judge the implementation, but the supposed behaviour should
be a step forward for paceful coexistence of Xorg server, Mesa and NVidia
driver.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20110705/9d5c5f51/attachment.pgp