Date: Tue, 5 Jul 2011 08:32:51 -0400 From: "b. f." <bf1783@googlemail.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: "freebsd-x11@FreeBSD.org" <freebsd-x11@freebsd.org>, danfe@freebsd.org Subject: Re: x11/nvidia-driver incompatible with portmaster? Message-ID: <CAGFTUwN41mVsJ0VY2bZgN8Y-_74YPaNTMy%2Bxe0jzJ8Ocp1sGdg@mail.gmail.com> In-Reply-To: <20110705095600.GE48734@deviant.kiev.zoral.com.ua> References: <CAGFTUwMPV9Tge6%2BGZO879KD7dh6Sr6%2BfPGK97SGvRndBitMTjg@mail.gmail.com> <4E0FCDD1.7050809@missouri.edu> <4E0FD8DC.20700@missouri.edu> <CAGFTUwM-c4WvkX01iuDh4kWcjX8kLKv9Gm1297orPMgNyV_1Cg@mail.gmail.com> <20110703114104.GK48734@deviant.kiev.zoral.com.ua> <CAGFTUwM2VMBsWmxQ70PkNcDfPb_JOBUw7N1wZOVsXfPPSQic1g@mail.gmail.com> <20110703140400.GO48734@deviant.kiev.zoral.com.ua> <CAGFTUwPHREj=oucqCihCpYB%2BzdZR3Vtkztaod9EbV2SaP679HA@mail.gmail.com> <20110705095600.GE48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/5/11, Kostik Belousov <kostikbel@gmail.com> wrote:
> On Tue, Jul 05, 2011 at 05:58:53AM +0000, b. f. wrote:
>> On 7/3/11, Kostik Belousov <kostikbel@gmail.com> wrote:
>> > On Sun, Jul 03, 2011 at 12:45:50PM +0000, b. f. wrote:
>> >> On 7/3/11, Kostik Belousov <kostikbel@gmail.com> wrote:
>> >> > On Sun, Jul 03, 2011 at 03:54:15AM +0000, b. f. wrote:
>> >> >> On 7/3/11, Stephen Montgomery-Smith <stephen@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.
>
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGFTUwN41mVsJ0VY2bZgN8Y-_74YPaNTMy%2Bxe0jzJ8Ocp1sGdg>