Hello,
On Sat, 04 Apr 2020, [email protected] wrote:
>On 04/04 08:36, David Haller wrote:
[..]
>> Looking at the ebuild, it seems that it only installs libnvoptix when
>> multilib enabled is *and* if it's on amd64:
>>
>> ==== x11-drivers/nvidia-drivers/nvidia-drivers-440.64.ebuild ====
>> if use kernel_linux && has_multilib_profile && [[ ${ABI} ==
>> "amd64" ]];
>a
>> then
>> NV_GLX_LIBRARIES+=(
>> "libnvidia-cbl.so.${NV_SOVER}"
>> "libnvidia-rtcore.so.${NV_SOVER}"
>> "libnvoptix.so.${NV_SOVER}"
>> )
>> fi
>> ====
>>
>> And that's the only occurrence of optix in the ebuild. In driver,
>> there's only a 64-bit libnvoptix.so.440.64 included, it's missing from
>> the ./32 subfolder, so I guess that optix stuff it's 64bit only.
>> But that dep on has_multilib_profile seems buggish to me. Test /
>> workaround: Just add 'multilib' to your package.use flags of
>> x11-drivers/nvidia-drivers (and _do not set_ e.g. abi_x86_32), just
>> switch on the 'multilib'. If that works and libnvoptix.so is then
>> installed and Blender works with it, I'd say it's a bug that those
>> libs should only be installed with multilib on. My guess is, that the
>> intent and/or right way would be to just omit that multilib dep. Apart
>> from other useflags that could be used. I.e. it should be:
>>
>> ====
>> if use kernel_linux && [[ ${ABI} == "amd64" ]];
>> then
>> NV_GLX_LIBRARIES+=(
>> "libnvidia-cbl.so.${NV_SOVER}"
>> "libnvidia-rtcore.so.${NV_SOVER}"
>> "libnvoptix.so.${NV_SOVER}"
>> )
>> fi
>> ====
[..]
>ooouuuhhhh...now things are becoming really weird...:
Not really ;)
>After reading your post (thanks for the indepth analysis!!!)m I set this:
>>=x11-drivers/nvidia-drivers-396.24-r2 X static-libs uvm compat driver acpi
>>multilib
>
>and got this:
>[I] x11-drivers/nvidia-drivers
> Available versions: (~)304.137-r1(0/304)^md[1]
> (~)340.107-r2(0/340)^md[1] 340.108(0/340)^mtd (~)375.82-r2(0/375)^md[1]
> (~)378.13-r5(0/378)^md[1] (~)381.22-r3(0/381)^md[1]
> (~)384.130-r1(0/384)^md[1] (~)387.34-r1(0/387)^md[1]
> (~)390.77-r1(0/390)^md[1] (~)390.87(0/390)^md[1] 390.132-r1(0/390)^mtd
> (~)390.132-r2(0/390)^mtd (~)396.24-r2(0/396)^md[1]
> (~)396.24.10-r1(0/396.24)^md[1] (~)396.45-r1(0/396)^md[1]
> (~)396.51-r1(0/396)^md[1] (~)396.51.02(0/396.51)^md[1] (~)396.54(0/396)^md[1]
> 430.64-r1(0/430)^mtd 435.21-r1(0/435)^mtd 440.64(0/440)^mtd {+X acpi compat
> +driver gtk3 +kms +libglvnd multilib pax_kernel static-libs +tools uvm
> wayland ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64"
> ABI_X86="32 64 x32" KERNEL="FreeBSD linux"}
> Installed versions: 440.64(0/440)^mtd(09:06:52 AM 04/04/2020)(X acpi
> compat driver kms libglvnd static-libs tools uvm -gtk3 -multilib -wayland
> ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64"
> ABI_X86="64 -32 -x32" KERNEL="linux -FreeBSD")
> Homepage: https://www.nvidia.com/
> Description: NVIDIA Accelerated Graphics Driver
>
>...multilib is ignored....
Did you reemerge x11-drivers/nvidia-drivers? If so your profile might
have switched if off and then read on ;)
>...because I am on a 64bit-only system???
Possibly, I'm not firm about all that profile stuff. If you've
selected a no-multilib profile (e.g.
default/linux/amd64/17.1/no-multilib), I guess that -multilib might be
switched off by the profile, even overriding your useflag in
package.use[0].
In that case, try this (create dirs/files as neccessary):
==== /etc/portage/profile/package.use.force ===
x11-drivers/nvidia-drivers multilib
====
If that does not work, try:
==== /etc/portage/profile/package.use.mask ===
x11-drivers/nvidia-drivers -multilib
====
(it's a matter of how it's switched off via the profile, AFAIK).
BTW: you do not have to emerge the package to see the effect of those
edits, an 'emerge --pretend ...' will show you if the 'multilib' flag
will be honored or not.
>By the way: For testing purposes, I installed the nvidia-drivers as
>they are provided by nvidia and can activate Optix in blender then.
>I prefer the "Gentoo-way", though.
Yeah, I do too, even though I do mess with it quite a bit :)
>Hmmmm...
>
>And: ABI_X86="64 -32 -x32" does not include "amd64" but only "64"...
ABI_X86 is a USE_EXPAND and so ABI_X86="64" expands to abi_x86_64 and
_that_ in effect sets the ABI multibuild environment variable to "amd64"
if you're building for x86_64 and not if building for e.g. x86_32 or
ppc or whatnot.
Dunno where that's documented though. Search 'ABI site:gentoo.org'?
HTH,
-dnh
[0] Which BTW makes no sense to me. Who does not set useflags in
package.use out of a reason? Why do useflags from the profile
override those in package.use?
[1] on my box and in other cases I'd just copy stuff to my local
overlay and adjust the ebuild as suggested (and see if it works) ;)
As I do with many dozens of others (most adjustments are just
personal taste, cosmetic and not worthy of any upstreaming ;)
--
Bored? Want hours of entertainment? Just set the initdefault to 6! Whee!
