summary refs log tree commit diff
path: root/pkgs/development/libraries/epoxy
Commit message (Collapse)AuthorAge
* epoxy: do not depend on python2Jan Tojnar2019-12-15
|
* treewide: remove redundant quotesvolth2019-09-08
|
* treewide: name -> pname (easy cases) (#66585)volth2019-08-15
| | | | | | | | | treewide replacement of stdenv.mkDerivation rec { name = "*-${version}"; version = "*"; to pname
* epoxy: 1.5.2 -> 1.5.3Dmitry Kalinkin2018-11-19
|
* epoxy: 1.5.1 -> 1.5.2 (#47178)Alexander V. Nikolaev2018-09-25
| | | | libgl-path.patch was updated (it applied with little fuzz, because I am a bit lazy, and rebase it on master of epoxy, not 1.5.2)
* libepoxy: 1.5.0 -> 1.5.1Will Dietz2018-04-29
|
* tree-wide: disable `doCheck` and `doInstallCheck` where it fails (the ↵Jan Malakhovski2018-04-25
| | | | trivial part)
* epoxy: explicitly search libGL path as fallbackWill Dietz2018-04-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't rely on questionable impact of DT_RPATH on dlopen(). This is a bit of a messy subject, but probably the clearest reference to motivate *not* relying on how dlopen() behaves in the presence of RPATH or RUNPATH is the following: https://sourceware.org/ml/libc-hacker/2002-11/msg00011.html FWIW the dlopen() manpage only mentions the the RPATH and RUNPATH in the "executable file for the calling program"; no mention of the executable files for libraries-- this has been brought to the attention of the relevant parties and AFAICT nothing has been done. The best reference for glibc behavior is apparently to ... "try it and see". Luckily a generous soul did exactly that and reported the findings: https://www.spinics.net/lists/linux-man/msg02291.html Qt wrote on the subject a bit when they were bit by this, linking to the above articles (directly or indirectly). See: http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/ -------- Since we know the path of libGL at build-time for libepoxy, there's a simple solution we can use to avoid all of this: simply teach libepoxy to explicitly look in the libGL path. This commit patches libepoxy to accomplish this, looking to "LIBGL_PATH" as a fallback if it cannot find the libraries otherwise. --------- This fixes use of libepoxy w/musl on NixOS!
* epoxy: fix darwin buildxeji2018-03-18
|
* Merge branch 'master' into stagingJan Malakhovski2018-03-10
|\ | | | | | | | | | | | | | | | | | | | | Resolved the following conflicts (by carefully applying patches from the both branches since the fork point): pkgs/development/libraries/epoxy/default.nix pkgs/development/libraries/gtk+/3.x.nix pkgs/development/python-modules/asgiref/default.nix pkgs/development/python-modules/daphne/default.nix pkgs/os-specific/linux/systemd/default.nix
| * treewide: transition mesa to libGLU_combinedAlexander V. Nikolaev2018-02-24
| |
* | epoxy: 1.3.1 -> 1.5.0xeji2018-03-02
| |
* | epoxy: add mesa to libepoxy runpath as fallbackxeji2018-02-23
|/ | | | | | - libepoxy dlopen()s libEGL / libGL but didn't have mesa in its runpath -> error unless lib is already open or in LD_LIBRARY_PATH - change dependency from mesa (should be avoided) to mesa_nonglu
* treewide: Shuffle outputsTuomas Tynkkynen2016-08-29
| | | | Make either 'bin' or 'out' the first output.
* Merge staging into closure-sizeVladimír Čunát2015-11-20
|\ | | | | | | | | | | The most complex problems were from dealing with switches reverted in the meantime (gcc5, gmp6, ncurses6). It's likely that darwin is (still) broken nontrivially.
| * darwin: fix gtk+3 dependenciesJude Taylor2015-10-27
| |
* | epoxy: split the "dev" outputVladimír Čunát2015-10-13
|/
* epoxy: 1.2 -> 1.3.1William A. Kennington III2015-08-13
|
* libepoxy: enable on DarwinSpencer Whitt2015-05-22
|
* Add epoxy: A library for handling OpenGL function pointer managementCillian de Róiste2014-07-27