NXv3 (redistributed) https://cgit.arctica-project.org/nx-libs/atom?h=3.5.99.14 2018-02-08T20:48:27+00:00 2018-02-08T20:48:27+00:00 Mihai Moldovan ionic@ionic.de 2018-02-08T19:40:32+00:00 urn:sha1:f76d4b54118627adb13dd896537c01033d989158 On PPC64*, X_BYTE_ORDER was hardcoded to X_BIG_ENDIAN. Since the CPUs support both modes and we actually intend to execute nxagent on ppc64le as well, detect the actual endianess and add support for Ppc64LeArchitecture. 2018-01-11T09:01:22+00:00 Mihai Moldovan ionic@ionic.de 2018-01-11T09:01:18+00:00 urn:sha1:7c43682e8e7a4f11af08a1b5e80244218adaa52d No change to the actually installed relinked nxagent(-relink) binary that gets installed - only affects the temporary executable build binary. 2018-01-08T21:53:00+00:00 Ulrich Sibiller uli42@gmx.de 2018-01-08T21:25:35+00:00 urn:sha1:43456713ba71d2e587ebbdbf0415e83f0294b1d5 Got dropped by accident in 9bc6ff269aa8bf4c41696ebf4a686c93729ba151 Fixes ArcticaProject/nx-libs#589 2017-12-30T02:36:11+00:00 Mihai Moldovan ionic@ionic.de 2017-12-29T23:17:57+00:00 urn:sha1:ecaa13ce6817282c1b9a3a75a2c022876834be83 We need this to be able to execute the resulting nxagent binary from within the build directory. 2017-12-30T02:36:11+00:00 Mihai Moldovan ionic@ionic.de 2017-12-29T20:44:56+00:00 urn:sha1:ffc09a73d3fad32f3765caf62546a3e7cc5b9cd8 While the install target explicitly installs the relinked system-location version of a program, we do not actually use this. Currently, we copy nxagent directly out of the build root. 2017-12-30T02:36:11+00:00 Mihai Moldovan ionic@ionic.de 2017-12-28T22:12:50+00:00 urn:sha1:4b153f5b057c0f8bd476883c009a91aaba03575b 2017-12-30T02:36:11+00:00 Mihai Moldovan ionic@ionic.de 2017-12-26T03:06:40+00:00 urn:sha1:26ab7b8a79e6c901518d9136d00b79e2905dab58 As discussed in ArcticaProject/nx-libs#610, we need a way to load libNX_X11 as a fake version of libX11 into nxagent's address space. For doing so, we have to link against libX11 at build-time and specify a(n) RPATH/RUNPATH to our libX11 -> libNX_X11 compat symlinks. This commit is essentially doing a cross between options 3 and 4 discussed in the provided GH issue. We link libX11 early (before specifying -Lcompat_symlinks_dir), so that the linker finds the "real" libX11 version with the libX11 SONAME. This leads to our binary depending upon both libX11 and libNX_X11 SONAMEs. We already always added RPATH/RUNPATH, but these values are not passed down to dependent libraries. What happens at run-time is that the loader searches for a libX11 SONAME, takes RPATH/RUNPATH into account and loads our libNX_X11 library instead via the compat symlinks. This satisfies the libX11 SONAME and dependent libraries will *not* load the system libX11 version again. Debian's dpkg-shlibdeps isn't quite happy about this mismatching SONAME situation, so instruct to look the other way while we're minding our business. Fixes: ArcticaProject/nx-libs#610 2017-12-16T06:18:24+00:00 Mihai Moldovan ionic@ionic.de 2017-12-16T06:18:11+00:00 urn:sha1:e92c2a87808ec922b6bc90d5d5002ca77318f697 Legacy Xext proto versions are automatically detected by the main Makefile. 2017-12-16T03:05:34+00:00 Mihai Moldovan ionic@ionic.de 2017-12-16T02:55:58+00:00 urn:sha1:fe011b55df68b7419a8042db94fc3fd1bcaca497 Partly reverts ec30a857eb0d67b232f8d43e63a6370023f4c4d0, but in a forward-compatible manner. Legacy libXfont1 versions are automatically detected by the main Makefile. 2017-12-15T16:00:14+00:00 Mihai Moldovan ionic@ionic.de 2017-12-15T16:00:11+00:00 urn:sha1:a10b9c649eda1f30e935c2fe4364f023fb5c957f Just copy-paste the initial definition to avoid recursion.