Re: gnulib's obstack_* symbols in dynamic exports on glibc. Intentional?

2022-12-30 Thread Sergei Trofimovich
On Fri, 30 Dec 2022 19:26:48 +0100 Bruno Haible wrote: > Sergei Trofimovich wrote: > > to my surprise it did have one a set of dynamically exported symbols: > > > > $ nm -D `which ls` | grep -v '^ ' > > 004c0d40 T _obstack_allocated_p > > 00534808 D

Re: gnulib's obstack_* symbols in dynamic exports on glibc. Intentional?

2022-12-30 Thread Bruno Haible
Sergei Trofimovich wrote: > to my surprise it did have one a set of dynamically exported symbols: > > $ nm -D `which ls` | grep -v '^ ' > 004c0d40 T _obstack_allocated_p > 00534808 D obstack_alloc_failed_handler > 004c0bd0 T _obstack_begin >

gnulib's obstack_* symbols in dynamic exports on glibc. Intentional?

2022-12-30 Thread Sergei Trofimovich
Hello bug-gnulib (and libc-alpha, CCed)! The other day I was looking at simplest programs to make sure they don't normally have dynamic exports. I picked coreutils-9.1 'ls'. And to my surprise it did have one a set of dynamically exported symbols: $ nm -D `which ls` | grep -v '^ '

[PATCH] ACL handling simplification + support for NFSv4

2022-12-30 Thread Ondrej Valousek
The following patch is aiming to improve & simplify ACL handling in copy-acl.c Changes/Benefits: * we no longer try to decode ACLs, instead we just copy the whole xattr with ACLs making the code simpler and faster * side effect is support for NFSv4 acls Disadvantages: * I agree the patch is