Re: Clang-built Gawk 5.2.1 regex oddity

Hi, Paul Eggert writes: > This is a serious bug in Clang: it generates incorrect machine code. > > The code that Clang generates for the following (gawk/support/dfa.c lines > 1141-1143): > > ((dfa->syntax.dfaopts & DFA_CONFUSING_BRACKETS_ERROR > ? dfaerror : dfawarn) > (_("charact

Re: [PATCH] Use xattr (Linux) in qcopy-acl.c

On 2023-01-05 02:32, Bruno Haible wrote: Yes, this is OK. I can work on the linker dependencies shortly after your patch is in. Basically it consists in compiling a testdir Sure, as long as the linker dependencies are fixed soon we'll be OK.

getpass: Fix compilation error on Android

On Android, I'm seeing this compilation error: clang -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC -DEXEEXT=\"\" -I. -I../../gllib -I.. -DGNULIB_STRICT_CHECKING=1 -I/data/data/com.termux/files/home/local/include -Wall -fvisibility=hidden -O2 -c -o getpass.o ../../gllib/getpass.c ../

string: Fix compilation errors in C++ mode on Android

On Android, I'm seeing these compilation errors: ../gllib/string.h:855:1: error: reference to overloaded function could not be resolved; did you mean to call it? _GL_CXXALIASWARN (memrchr); ^~ ../gllib/string.h:1010:1: error: reference to overloaded function could not be

Re: xmalloc calling undeclared xalloc_die function

* Bruno Haible: > Florian Weimer wrote: >> lib/xmalloc.c contains this function definition, unconditionally: >> >> static void * _GL_ATTRIBUTE_PURE >> nonnull (void *p) >> { >> if (!p) >> xalloc_die (); >> return p; >> } >> >> But the declaration of xalloc_die in lib/xalloc

Recognize functions added in future versions of Android

Building a testdir on Android (API level 24), I get these compilation errors: clang -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC -DEXEEXT=\"\" -I. -I../../gllib -I.. -DGNULIB_STRICT_CHECKING=1 -I/data/data/com.termux/files/home/local/include -Wall -fvisibility=hidden -g -O2 -c -o s

Re: [PATCH] Use xattr (Linux) in qcopy-acl.c

Ondrej Valousek wrote: > Can we accept the patch as it is for now and work in the linker dependency > with a different commit perhaps? Yes, this is OK. I can work on the linker dependencies shortly after your patch is in. Basically it consists in compiling a testdir ./gnulib-tool --create-testd

copy-file, supersede: Fix link-time requirements

Yesterday, Ondrej noticed that the 'supersede' module does not mention $(LIB_ACL). But these .o files from the 'acl-permissions' module do need -lacl: acl-internal.o U acl_entries U acl_free U acl_get_entry U acl_get_tag_type ge

More systematic naming of LIB variables

In I wrote: Our convention for these variables is generally - $(LIBFOO) or $(LIB_FOO) for the library -lfoo (or empty if nonexistent or not needed), - $(MODULE_LIB) for the libraries needed by a given module. For exampl

RE: [PATCH] Use xattr (Linux) in qcopy-acl.c

Interesting. Can we accept the patch as it is for now and work in the linker dependency with a different commit perhaps? As I have to admit I am not quite sure what to do now. Ondrej -Original Message- From: Bruno Haible Sent: čtvrtek 5. ledna 2023 10:01 To: Paul Eggert ; bug-gnulib@gnu

Re: [PATCH] Use xattr (Linux) in qcopy-acl.c

Ondrej Valousek wrote: > Why don't we solve the linker problem with the "--as-needed" option? This > will make linker clever enough not to link libraries that are not needed. '--as-needed' is a can of worms in itself. In GNU gettext (IIRC) Debian used '--as-needed' in the link command line, and t

Re: [PATCH] Use xattr (Linux) in qcopy-acl.c

Paul Eggert wrote: > I see a problem in linking. With this change, programs using the > qcopy-acl module will link to both $(LIB_ACL) and $(LIB_XATTR), even > though they do not need to link with $(LIB_ACL). Perhaps you can fix > this by fixing the Link sections of the relevant modules to use >