Commit Graph

21 Commits

Author SHA1 Message Date
R. RyanTM
315642ae70 epoxy: 1.5.3 -> 1.5.4 2020-01-29 09:02:32 +01:00
Jan Tojnar
91a276cd79
epoxy: do not depend on python2 2019-12-15 01:50:35 +01:00
volth
7b8fb5c06c treewide: remove redundant quotes 2019-09-08 23:38:31 +00:00
volth
46420bbaa3 treewide: name -> pname (easy cases) (#66585)
treewide replacement of

stdenv.mkDerivation rec {
  name = "*-${version}";
  version = "*";

to pname
2019-08-15 13:41:18 +01:00
Dmitry Kalinkin
a2756a396f
epoxy: 1.5.2 -> 1.5.3 2018-11-19 11:54:14 -05:00
Alexander V. Nikolaev
867d387a1c epoxy: 1.5.1 -> 1.5.2 (#47178)
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)
2018-09-25 11:50:51 +02:00
Will Dietz
04380e713c libepoxy: 1.5.0 -> 1.5.1 2018-04-29 17:09:52 -05:00
Jan Malakhovski
7438083a4d tree-wide: disable doCheck and doInstallCheck where it fails (the trivial part) 2018-04-25 04:18:46 +00:00
Will Dietz
503f8efbcd epoxy: explicitly search libGL path as fallback
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!
2018-04-02 12:35:37 -05:00
xeji
b6ca572694 epoxy: fix darwin build 2018-03-18 13:36:14 +01:00
Jan Malakhovski
7079e744d4 Merge branch 'master' into staging
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
2018-03-10 20:38:13 +00:00
xeji
980dd63141 epoxy: 1.3.1 -> 1.5.0 2018-03-02 00:26:09 +01:00
Alexander V. Nikolaev
0acec7e984 treewide: transition mesa to libGLU_combined 2018-02-24 17:06:49 +02:00
xeji
a7a0d78f1c epoxy: add mesa to libepoxy runpath as fallback
- 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
2018-02-23 10:38:34 +01:00
Tuomas Tynkkynen
a17216af4c treewide: Shuffle outputs
Make either 'bin' or 'out' the first output.
2016-08-29 14:49:51 +03:00
Vladimír Čunát
333d69a5f0 Merge staging into closure-size
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.
2015-11-20 14:32:58 +01:00
Jude Taylor
950261bb9a darwin: fix gtk+3 dependencies 2015-10-27 00:38:06 -07:00
Vladimír Čunát
0a0e41b083 epoxy: split the "dev" output 2015-10-13 20:18:53 +02:00
William A. Kennington III
0bbe804f0a epoxy: 1.2 -> 1.3.1 2015-08-13 15:00:18 -07:00
Spencer Whitt
3d60104a74 libepoxy: enable on Darwin 2015-05-22 20:10:53 -04:00
Cillian de Róiste
e7bb85e448 Add epoxy: A library for handling OpenGL function pointer management 2014-07-27 12:14:38 +02:00