nordic-dev.net/nixpkgs
nordic-dev.net/nixpkgs
2
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2024-12-29 17:14:33 +00:00
Code Issues Packages Projects Releases Wiki Activity
3b4631d601
nixpkgs/pkgs/tools/X11/primus/default.nix

35 lines
1.2 KiB
Nix
Raw Normal View History

Add primus and extend bumblebee to support 32bit/64bit multilib architectures. Using primusrun will work as expected in a multilib environment. Even if the initial program executes a antoehr program of the another architecture. Assuming the program does not modify LD_LIBRARY_PATH inappropriately. This does not update virtualgl for seemless multilib. I was unable to get a mixed 64/32 bit environment to work with VirtualGL. The mechanism VirtualGL uses to inject the fake GL library would fail if both 32bit and 64 bit libraries were in the environment. Instead the bumblebee package creates a optirun32 executable that can be used to run a 32bit executable with optimus on a 64 bit host. This is not created if the host is 32bit. For my usage, gaming under wine, the primusrun executable works as expected regardless of 32bit/64bit.
2014-05-03 14:28:21 +00:00
# For a 64bit + 32bit system the LD_LIBRARY_PATH must contain both the 32bit and 64bit primus
# libraries. Providing a different primusrun for each architecture will not work as expected. EG:
# Using steam under wine can involve both 32bit and 64bit process. All of which inherit the
# same LD_LIBRARY_PATH.
# Other distributions do the same.
{ stdenv
primus: propagate stdenv to primusLibs
2016-03-31 16:51:15 +00:00
, stdenv_i686
linuxPackages.nvidia_x11: refactor, build more from source * Use libglvnd; * Compile nvidia-settings, nvidia-persistenced from source; * Generalize builder.
2017-01-29 21:29:39 +00:00
, lib
Add primus and extend bumblebee to support 32bit/64bit multilib architectures. Using primusrun will work as expected in a multilib environment. Even if the initial program executes a antoehr program of the another architecture. Assuming the program does not modify LD_LIBRARY_PATH inappropriately. This does not update virtualgl for seemless multilib. I was unable to get a mixed 64/32 bit environment to work with VirtualGL. The mechanism VirtualGL uses to inject the fake GL library would fail if both 32bit and 64 bit libraries were in the environment. Instead the bumblebee package creates a optirun32 executable that can be used to run a 32bit executable with optimus on a 64 bit host. This is not created if the host is 32bit. For my usage, gaming under wine, the primusrun executable works as expected regardless of 32bit/64bit.
2014-05-03 14:28:21 +00:00
, primusLib
primus: 1.0.0748176 -> 20151204, add useNvidia flag
2015-12-04 21:31:10 +00:00
, writeScriptBin
treewide: use runtimeShell instead of stdenv.shell whenever possible Whenever we create scripts that are installed to $out, we must use runtimeShell in order to get the shell that can be executed on the machine we create the package for. This is relevant for cross-compiling. The only use case for stdenv.shell are scripts that are executed as part of the build system. Usages in checkPhase are borderline however to decrease the likelyhood of people copying the wrong examples, I decided to use runtimeShell as well.
2019-02-26 11:45:54 +00:00
, runtimeShell
Add primus and extend bumblebee to support 32bit/64bit multilib architectures. Using primusrun will work as expected in a multilib environment. Even if the initial program executes a antoehr program of the another architecture. Assuming the program does not modify LD_LIBRARY_PATH inappropriately. This does not update virtualgl for seemless multilib. I was unable to get a mixed 64/32 bit environment to work with VirtualGL. The mechanism VirtualGL uses to inject the fake GL library would fail if both 32bit and 64 bit libraries were in the environment. Instead the bumblebee package creates a optirun32 executable that can be used to run a 32bit executable with optimus on a 64 bit host. This is not created if the host is 32bit. For my usage, gaming under wine, the primusrun executable works as expected regardless of 32bit/64bit.
2014-05-03 14:28:21 +00:00
, primusLib_i686 ? null
primus: 1.0.0748176 -> 20151204, add useNvidia flag
2015-12-04 21:31:10 +00:00
, useNvidia ? true
Add primus and extend bumblebee to support 32bit/64bit multilib architectures. Using primusrun will work as expected in a multilib environment. Even if the initial program executes a antoehr program of the another architecture. Assuming the program does not modify LD_LIBRARY_PATH inappropriately. This does not update virtualgl for seemless multilib. I was unable to get a mixed 64/32 bit environment to work with VirtualGL. The mechanism VirtualGL uses to inject the fake GL library would fail if both 32bit and 64 bit libraries were in the environment. Instead the bumblebee package creates a optirun32 executable that can be used to run a 32bit executable with optimus on a 64 bit host. This is not created if the host is 32bit. For my usage, gaming under wine, the primusrun executable works as expected regardless of 32bit/64bit.
2014-05-03 14:28:21 +00:00
}:
primus: 1.0.0748176 -> 20151204, add useNvidia flag
2015-12-04 21:31:10 +00:00
Add primus and extend bumblebee to support 32bit/64bit multilib architectures. Using primusrun will work as expected in a multilib environment. Even if the initial program executes a antoehr program of the another architecture. Assuming the program does not modify LD_LIBRARY_PATH inappropriately. This does not update virtualgl for seemless multilib. I was unable to get a mixed 64/32 bit environment to work with VirtualGL. The mechanism VirtualGL uses to inject the fake GL library would fail if both 32bit and 64 bit libraries were in the environment. Instead the bumblebee package creates a optirun32 executable that can be used to run a 32bit executable with optimus on a 64 bit host. This is not created if the host is 32bit. For my usage, gaming under wine, the primusrun executable works as expected regardless of 32bit/64bit.
2014-05-03 14:28:21 +00:00
let
primus: propagate stdenv to primusLibs
2016-03-31 16:51:15 +00:00
# We override stdenv in case we need different ABI for libGL
primusLib_ = primusLib.override { inherit stdenv; };
primusLib_i686_ = primusLib_i686.override { stdenv = stdenv_i686; };
primus = if useNvidia then primusLib_ else primusLib_.override { nvidia_x11 = null; };
primus_i686 = if useNvidia then primusLib_i686_ else primusLib_i686_.override { nvidia_x11 = null; };
primus: fix if nvidia is not used Fixes #23628
2017-03-08 20:07:15 +00:00
ldPath = lib.makeLibraryPath (lib.filter (x: x != null) (
[ primus primus.glvnd ]
++ lib.optionals (primusLib_i686 != null) [ primus_i686 primus_i686.glvnd ]
));
primus: 1.0.0748176 -> 20151204, add useNvidia flag
2015-12-04 21:31:10 +00:00
in writeScriptBin "primusrun" ''
treewide: use runtimeShell instead of stdenv.shell whenever possible Whenever we create scripts that are installed to $out, we must use runtimeShell in order to get the shell that can be executed on the machine we create the package for. This is relevant for cross-compiling. The only use case for stdenv.shell are scripts that are executed as part of the build system. Usages in checkPhase are borderline however to decrease the likelyhood of people copying the wrong examples, I decided to use runtimeShell as well.
2019-02-26 11:45:54 +00:00
#!${runtimeShell}
treewide: Fix unsafe concatenation of $LD_LIBRARY_PATH Naive concatenation of $LD_LIBRARY_PATH can result in an empty colon-delimited segment; this tells glibc to load libraries from the current directory, which is definitely wrong, and may be a security vulnerability if the current directory is untrusted. (See #67234, for example.) Fix this throughout the tree. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
2020-01-02 00:29:34 +00:00
export LD_LIBRARY_PATH=${ldPath}''${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH
primus: fix for libglvnd Fixes #48795.
2019-07-17 08:44:00 +00:00
# https://bugs.launchpad.net/ubuntu/+source/bumblebee/+bug/1758243
export __GLVND_DISALLOW_PATCHING=1
Add primus and extend bumblebee to support 32bit/64bit multilib architectures. Using primusrun will work as expected in a multilib environment. Even if the initial program executes a antoehr program of the another architecture. Assuming the program does not modify LD_LIBRARY_PATH inappropriately. This does not update virtualgl for seemless multilib. I was unable to get a mixed 64/32 bit environment to work with VirtualGL. The mechanism VirtualGL uses to inject the fake GL library would fail if both 32bit and 64 bit libraries were in the environment. Instead the bumblebee package creates a optirun32 executable that can be used to run a 32bit executable with optimus on a 64 bit host. This is not created if the host is 32bit. For my usage, gaming under wine, the primusrun executable works as expected regardless of 32bit/64bit.
2014-05-03 14:28:21 +00:00
exec "$@"
primus: 1.0.0748176 -> 20151204, add useNvidia flag
2015-12-04 21:31:10 +00:00
''
Reference in New Issue Copy Permalink