nixpkgs/pkgs/tools/X11/primus/default.nix

# 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
, stdenv_i686
, primusLib
, writeScriptBin
, primusLib_i686 ? null
, useNvidia ? true
}:

let
  # 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; };
  ldPath = stdenv.lib.makeLibraryPath ([primus] ++ stdenv.lib.optional (primusLib_i686 != null) primus_i686);

in writeScriptBin "primusrun" ''
  #!${stdenv.shell}
  export LD_LIBRARY_PATH=${ldPath}:$LD_LIBRARY_PATH
  exec "$@"
''
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 15:28:21 +01: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 17:51:15 +01:00			`, stdenv_i686`
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 15:28:21 +01:00			`, primusLib`
primus: 1.0.0748176 -> 20151204, add useNvidia flag 2015-12-04 21:31:10 +00:00			`, writeScriptBin`
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 15:28:21 +01: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 15:28:21 +01: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 15:28:21 +01:00			`let`
primus: propagate stdenv to primusLibs 2016-03-31 17:51:15 +01: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: 1.0.0748176 -> 20151204, add useNvidia flag 2015-12-04 21:31:10 +00:00			`ldPath = stdenv.lib.makeLibraryPath ([primus] ++ stdenv.lib.optional (primusLib_i686 != null) primus_i686);`

			`in writeScriptBin "primusrun" ''`
			`#!${stdenv.shell}`
primus: remove old workaround, fix LD_LIBRARY_PATH 2015-03-09 20:01:32 +00:00			`export LD_LIBRARY_PATH=${ldPath}:$LD_LIBRARY_PATH`
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 15:28:21 +01:00			`exec "$@"`
primus: 1.0.0748176 -> 20151204, add useNvidia flag 2015-12-04 21:31:10 +00:00			`''`