Simply looking at libtool redefines LINK globally to use libtool, which when
you're trying to cross-compile to Windows can cause complications.
As in src/util/ we're simply building a small binary for the build host, reset
LINK to the automake default so that the traditional compile/link steps occur
without libtool.
Also remove -all-static from LDFLAGS as that is a libtool-specific argument
intended to solve this problem.
Closes: #100
Signed-off-by: Ross Burton <ross.burton@intel.com>
to remove the fake quotes replace them with propper
predefined macros \*(lq and \*(rq. this will allow
nroff to choose the propper characters when using ps etc.
Signed-off-by: Walter Harms <wharms@bfs.de>
after converting everything to st. man page macros there is
no need to maintain X11 private nroff macros, so remove them.
Signed-off-by: Walter Harms <wharms@bfs.de>
Same pages use the man page .EX/.EE macro. Replace all occurences
of .De/.Ds with the std. macros to make the code better to maintain.
Signed-off-by: Walter Harms <wharms@bfs.de>
Replace the home grown macro .ZN with std. macros
from man macro paket. So we can get rid of the
definition an get a clean header.
Signed-off-by: Walter Harms <wharms@bfs.de>
Subsequent to a121b7b0c2 we are no longer
building makekeys with enough -I/foo/bar to find the X11 headers, so if
they're not in a system include path, things fail. Since this utility is
only needed at build time, there's no real reason to demand the X
headers be installed for both the build and target machines if cross-
compiling, we can just assume a vaguely ANSI environment instead.
Tested-by: Niclas Zeising <zeising@daemonic.se>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
... and include config.h in makekeys.c to get the definition of
_FILE_OFFSET_BITS. Without it, libX11 can fail to build on a file
system with 64-bit inode numbers.
Bug: https://bugs.gentoo.org/550502
Bug: https://bugs.gentoo.org/616140
Signed-off-by: Matt Turner <mattst88@gmail.com>
The man page says:
Strings may be direct text encoded in the locale for which the
compose file is to be used, or an escaped octal or hexadecimal
character code. Octal codes are specified as "\123" and
hexadecimal codes as "\0x123a".
But the grammar in the parser and the implementation say:
ESCAPED_CHAR ::= ('\\' | '\"' | OCTAL | HEX )
HEX ::= '\' (x|X) HEX_CHAR [HEX_CHAR]]
HEX_CHAR ::= (0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F|a|b|c|d|e|f)
So "\0x123a" -> "\x3a".
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
a simple snippet like XFreeFontSet(d, XCreateFontSet(d, ...)) will generate lots of memory leaks,
as evidenced by the following valgrind output:
==983== HEAP SUMMARY:
==983== in use at exit: 39,409 bytes in 341 blocks
==983== total heap usage: 4,795 allocs, 4,454 frees, 489,086 bytes allocated
==983==
==983== 1,688 (136 direct, 1,552 indirect) bytes in 1 blocks are definitely lost in loss record
40 of 46
==983== at 0x4C2B042: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==983== by 0x56D5A93: add_codeset.clone.9 (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56D5FE0: load_generic (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56D7612: initialize (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56D7E75: _XlcCreateLC (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56F9A5F: _XlcUtf8Loader (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56DF815: _XOpenLC (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56B255A: XOpenOM (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56A665A: XCreateFontSet (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x4FCA80: conky::x11_output::create_gc() (x11.cc:746)
==983== by 0x4FC3B4: conky::x11_output::use_own_window() (x11.cc:602)
==983== by 0x4FAD42: conky::priv::own_window_setting::set(bool const&, bool) (x11.cc:92)
==983==
==983== LEAK SUMMARY:
==983== definitely lost: 136 bytes in 1 blocks
==983== indirectly lost: 1,552 bytes in 34 blocks
==983== possibly lost: 0 bytes in 0 blocks
==983== still reachable: 37,721 bytes in 306 blocks
==983== suppressed: 0 bytes in 0 blocks
This patch makes the leak dissappear (Well, at least the "definitely lost part". The "still
reachable" thingy remains). After some analysis, I've discovered that the XLCd structure is
destroyed improperly. The "constructor" is in lcGeneric.c, but the structure is destroyed using
code from lcPublic.c. I've found that changing the destructor call to _XlcDestroyLC executes the
correct code path, and I'm pretty sure this is correct (the object was constructed using
_XlcCreateLC, it make sense to destroy it using its conterpart).
So far I haven't observed any strange behaviour on my system caused by this change (although, I'm
not sure, how many programs actually use this function).
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
For Windows targets, libtool uses a wrapper executable, not a wrapper
script (see [1]), which it compiles with the host compiler. This
doesn't work when cross-compiling.
Since we don't actually need to link with anything, use the libtool flag
-all-static to tell it to stay completely out of this.
[1] https://www.gnu.org/software/libtool/manual/html_node/Wrapper-executables.html
Use EXEXT_FOR_BUILD, to fix cross-compiling where EXEEXT differs from
EXEEXT_FOR_BUILD, such as when building for Windows from unix.
(Note: As written, this assumes EXEEXT_FOR_BUILD is always empty when
cross-compiling. There could be some elaborate autodetection for
EXEXT_FOR_BUILD, but for the moment, if you are cross-compiling from
Windows to Unix, you'll need to set EXEEXT_FOR_BUILD explicity...)
This is the patch from https://bugs.freedesktop.org/show_bug.cgi?id=6669
by Pierre Ossman, reworked for master.
Avoid using LIBS (which are for host, but we don't need) and rewrite
makekeys slightly to avoid needing to include any X headers, which
avoids potentially having -I with host paths in CFLAGS, which can cause
standard headers e.g. stdio.h for the host to also be used, which can
break things...
On finishing releasing Braille keys, we should clear the just-commited
pattern, to reset the state to initial state, and avoid having to wait for
0.3s before typing the next pattern.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: Jean-Philippe Mengual <jpmengual@hypra.fr>
This fixes a bug where concurrent threads call XCreateColormap and
XFreeColormap corrupting a linked list where colormap structures
are stored.
Fixes: https://gitlab.freedesktop.org/xorg/lib/libx11/issues/94
v2: handle XCopyColormapAndFree also (Adam Jackson)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Currently, when the X server crashes or a client is disconnected with
XKillClient, you get a somewhat confusing error message from libX11
along the lines of:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 98 requests (40 known processed) with 0 events remaining.
What's happening here is the previous recvmsg has thrown EAGAIN, since
the socket is non-blocking. In this case, check whether the socket has
any more data to read, and if not treat it like EPIPE.
Signed-off-by: Adam Jackson <ajax@redhat.com>
In-tree builds found reallocarray.h in $(top_builddir)/src but the
out-of-tree build didn't find it at all.
Reported-by: Emmanuele Bassi <ebassi@gmail.com> from GNOME continuous integration pipeline
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
