NXv3 (redistributed) https://cgit.arctica-project.org/nx-libs/atom?h=pr%2Fvarious9 2021-10-30T19:17:30+00:00 2021-10-30T19:17:30+00:00 Ulrich Sibiller uli42@gmx.de 2021-10-18T20:54:32+00:00 urn:sha1:3ab28297ce6aa46dfc5f023a405e0ed8247aa881 2020-05-07T10:44:55+00:00 Ulrich Sibiller uli42@gmx.de 2020-01-29T22:12:33+00:00 urn:sha1:40997f84c915415b24655698c21f480e7ff56a4b We have never built nxwin within this tree. And we never shipped it. So drop the according logic. We have also removed CYGWIN stuff in the past so nxwin probably would not compile/work anyway... 2019-11-02T10:21:00+00:00 Ulrich Sibiller uli42@gmx.de 2019-10-28T19:30:23+00:00 urn:sha1:e54d2a39001bde60b6cca7795f3fa98b3e4111e6 instead of including it and creating NXextension.o we can simply use the dix version. There are no NX specials anymore. 2019-11-01T15:42:55+00:00 Ulrich Sibiller uli42@gmx.de 2019-10-30T17:34:05+00:00 urn:sha1:2a0994122ff23cdcb852596a457ce3e57e48f9df With the previous commits this file finally becomes obsolete. 2019-10-10T10:45:23+00:00 Ulrich Sibiller uli42@gmx.de 2019-09-28T19:32:07+00:00 urn:sha1:b55c66e8ab3ed004043c54101aae8935ca7471eb nxagent links system libraries that link against libX11. Unfortunately, nxagent (and libXcompshad) require a modified libX11 version, nicknamed libNX_X11, for proper functioning. Fortunately, this one can act as a drop-in replacement for the system libX11. So we’ll hack our way out: add a DT_NEEDED entry for libX11 by linking against the system library when building nxagent and link the other system libraries later and set DT_RUNPATH to a special directory containing symlinks from libNX_X11 to libX11. This tricks the loader into pulling in the "fake" libX11 version without checking its SONAME and thus satisfying the DT_NEEDED entry early on - specifically also for the system libraries. Ex.: readelf -a /usr/bin/nxagent | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libX11.so.6] ... 0x0000000000000001 (NEEDED) Shared library: [libNX_X11.so.6] ... If, however, you run the build a second time, it will find the newly created libX11 links in ../../exports/lib (used as an additional library search path) instead of the system libX11. The results in a binary looking like this: 0x0000000000000001 (NEEDED) Shared library: [libNX_X11.so.6] ... With such a setup, the whole magic falls apart and system libraries will suddenly pull in the actual system libX11 file. We initially believed a compiler call such as: ${CC} [--unrelated-options ...] [-Lunrelated_library_path ...] -lX11 [more options like -l and -L] -L../../exports/lib -lother_libraries to do "the right thing" and link against the system libX11 (or, at worst, a libX11 found in the library directory search list preceding the link call) and use ../../exports/lib only for later linking operations, since the order of options matters. However, this turned out to be blatantly wrong: while the order of -L arguments does matter for building the search path, the whole search path including elements from *ALL* -L arguments (and the system paths) will always be used when linking libraries. Hence, (counter-intuitively to us) both these calls will be equivalent: ${CC} [--unrelated-options ...] -la -Loverride_liba -lb [-Lunrelated_library_path ...] -lc ${CC} [--unrelated-options ...] -Loverride_liba [-Lunrelated_library_path ...] -la -lb -lc By removing LDPRELIBS from NXAGENTSYSLIBS, ../../exports/lib is no longer used during building/linking and the binaries are built reproducibly. We never intended to use this directory at link time anyway. 2019-06-11T10:09:27+00:00 Ulrich Sibiller uli42@gmx.de 2019-05-30T14:04:43+00:00 urn:sha1:073c6c17e768cf61a879cb100f5ad2cb16703518 The only left function is identical to the one in mi/miexpose.c. 2019-05-10T17:02:51+00:00 Ulrich Sibiller uli42@gmx.de 2019-05-01T18:11:14+00:00 urn:sha1:0312a8cfed0fa8211cb4cbc92a83bfb0233ac3ef upstream xorg is also using that name 2018-03-15T11:20:05+00:00 Mihai Moldovan ionic@ionic.de 2018-03-09T08:08:35+00:00 urn:sha1:25cc6fce5402549afdea25f9b4a7102d7ec04eaf 2018-03-15T11:20:05+00:00 Mihai Moldovan ionic@ionic.de 2018-03-15T11:18:21+00:00 urn:sha1:daebc8b6a9401db4f24ec48ed7a20d2a6bd0fa72 2018-03-15T11:20:05+00:00 Mihai Moldovan ionic@ionic.de 2018-03-09T08:07:15+00:00 urn:sha1:32dac66c6f375a96cd4fc466a553943864519a00