Re: Issue when testing with --as-needed enabled
Hello I'm sorry, I was not on the master branch. With an up to date gnulib version, I do not have this issue anymore. Thanks ! Regards Le dim. 3 janv. 2021 à 23:34, Bruno Haible a écrit : > Hi, > > Thomas Andrejak wrote: > > On debian 9 /10 / testing > > ... > > > > But, event with this patch, I still have build failure and I need to > do > > > > some patches like that : > > > > > > > > https://salsa.debian.org/totol-guest/libprelude/-/blob/master/debian/patches/013-fix-test_rwlock1.patch > > > > > > > > I don't know how to dig on this bug. > > > > > > > > Output : > > > > FAIL: test-rwlock1 > > > > == > > > > Unexpected outcome 3 > > > > FAIL test-rwlock1 (exit status: 134) > > I cannot reproduce this. I took a Debian 10.7 distribution, with gcc-8 as > compiler package. I created a testdir for all of gnulib. I configured it > in 3 ways: > - the normal way, > - with LDFLAGS="... -Wl,--as-needed" > - with CFLAGS="... -Wl,--as-needed" > and in all cases the build succeeded and all tests passed. > > So, you need to give *precise* instructions for how to reproduce it. > > Without reproducing, no one can give an analysis nor a fix. > > Bruno > >
Re: implicit declaration of function 'utime' in trailing slashes test
> >>> conftest.c:491:23: error: implicit declaration of function 'utime' is
> >>> invalid in C99 [-Werror,-Wimplicit-function-declaration]
> >>> if (!utime ("conftest.tmp/", NULL))
> >>>^
> >>> 1 error generated.
Thanks for the report. Fixed through the patch below.
> ARM processors have different calling conventions for variadic and
> non-variadic functions, so the compiler must know before you call a
> function what type of function it is, and the way it knows that is
> by the function declaration.
This is well-known for 'float' parameters (for a long time, on most
platforms).
Do you happen to know other cases for which this is the case? I'm asking
in order to check GNU libffcall and libffi w.r.t. this situation.
Bruno
2021-01-23 Bruno Haible
utime: Fix configure test (regression 2020-12-04).
Reported by Ryan Schmidt via Tim Rühsen in
.
* m4/utime.m4 (gl_FUNC_UTIME): In the test program, include ,
not .
diff --git a/m4/utime.m4 b/m4/utime.m4
index 03df7b7..4ed4158 100644
--- a/m4/utime.m4
+++ b/m4/utime.m4
@@ -1,4 +1,4 @@
-# utime.m4 serial 3
+# utime.m4 serial 4
dnl Copyright (C) 2017-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -34,7 +34,7 @@ AC_DEFUN([gl_FUNC_UTIME],
AC_RUN_IFELSE(
[AC_LANG_PROGRAM(
[[#include
- #include
+ #include
]],
[[int result = 0;
if (!utime ("conftest.tmp/", NULL))
[PATCH] libc-config: port to Xcode 7
Problem reported by Mattias Engdegård in: https://lists.gnu.org/r/emacs-devel/2021-01/msg01089.html * lib/cdefs.h (__nonnull): If already defined but glibc is not in use, override the definition with Gnulib’s _GL_ATTRIBUTE_NONNULL. This is needed for Xcode 7, which has a ‘#define __nonnull _Nonnull’ builtin for backwards-compatibility with an older Xcode syntax that GNUish code never uses. --- ChangeLog | 11 +++ lib/cdefs.h | 6 -- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index b1b81353e..43d1a1671 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,14 @@ +2021-01-23 Paul Eggert + + libc-config: port to Xcode 7 + Problem reported by Mattias Engdegård in: + https://lists.gnu.org/r/emacs-devel/2021-01/msg01089.html + * lib/cdefs.h (__nonnull): If already defined but glibc is not in + use, override the definition with Gnulib’s _GL_ATTRIBUTE_NONNULL. + This is needed for Xcode 7, which has a ‘#define __nonnull + _Nonnull’ builtin for backwards-compatibility with an older Xcode + syntax that GNUish code never uses. + 2021-01-23 Bastien Roucariès explicit_bzero: Add fallback for other compilers. diff --git a/lib/cdefs.h b/lib/cdefs.h index 060a3d068..6f12c79da 100644 --- a/lib/cdefs.h +++ b/lib/cdefs.h @@ -320,14 +320,16 @@ #endif /* The nonnull function attribute marks pointer parameters that - must not be NULL. Do not define __nonnull if it is already defined, - for portability when this file is used in Gnulib. */ + must not be NULL. */ #ifndef __nonnull # if __GNUC_PREREQ (3,3) || __glibc_has_attribute (__nonnull__) # define __nonnull(params) __attribute__ ((__nonnull__ params)) # else # define __nonnull(params) # endif +#elif !defined __GLIBC__ +# undef __nonnull +# define __nonnull(params) _GL_ATTRIBUTE_NONNULL (params) #endif /* If fortification mode, we warn about unused results of certain -- 2.29.2
Re: implicit declaration of function 'utime' in trailing slashes test
On 23.01.21 07:09, Ryan Schmidt wrote:
On Jan 22, 2021, at 16:47, Tim Rühsen wrote:
On 21.01.21 01:34, Ryan Schmidt wrote:
Hi, I'm the maintainer of wget in MacPorts.
In the version of clang included with Xcode 12 and later, implicit declaration
of functions is an error.
During configure, wget 1.12.1 prints this:
checking whether utime handles trailing slashes on files... no
config.log contains this:
configure:49368: checking whether utime handles trailing slashes on files
configure:49414: ccache /usr/bin/clang -o conftest -DNDEBUG -pipe -Os
-Werror=implicit-function-declaration -arch x86_64 -I/opt/local/include
-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c >&5
conftest.c:491:23: error: implicit declaration of function 'utime' is invalid
in C99 [-Werror,-Wimplicit-function-declaration]
if (!utime ("conftest.tmp/", NULL))
^
1 error generated.
configure:49414: $? = 1
configure: program exited with status 1
So the results of this test don't represent what you want them to.
This configure test uses #include . The problem goes away if I change that to
#include . Then configure output is still:
checking whether utime handles trailing slashes on files... no
but config.log then contains:
configure:49368: checking whether utime handles trailing slashes on files
configure:49414: ccache /usr/bin/clang -o conftest -DNDEBUG -pipe -Os
-Werror=implicit-function-declaration -arch x86_64 -I/opt/local/include
-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c >&5
configure:49414: $? = 0
configure:49414: ./conftest
configure:49414: $? = 2
configure: program exited with status 2
Now the results of the test are accurate.
I included this patch in the MacPorts wget 1.12.1 port:
https://github.com/macports/macports-ports/blob/13fd7facb9e1ea9e70b79c8c0b429058b9bb8698/net/wget/files/implicit.patch
Of course you'll want to patch m4/utime.m4 instead of configure.
./configure scripts are not made for using -Werror in CFLAGS.
This is documented somewhere but (sorry), I am just too tired to search for the
URL right now.
Unfortunately, you no longer have much of a choice. Treating implicit
declarations of functions as an error is the *default* behavior of the compiler
included with Xcode 12 and later.
In the output I showed above I have specified
-Werror=implicit-function-declaration manually in CFLAGS because I am using an
earlier version of Xcode but I want to simulate the experience of an Xcode 12
user so that I can identify and fix this type of problem.
Apple intentionally changed the default behavior of the compiler in order to be able to
ship Macintosh computers with ARM processors ("Apple Silicon"). ARM processors
have different calling conventions for variadic and non-variadic functions, so the
compiler must know before you call a function what type of function it is, and the way it
knows that is by the function declaration.
The C99 standard requires that you declare functions before you use them. It
has been this way for over 2 decades. wget should do so in all of its code,
regardless of whether the code is in a configure test or elsewhere.
This one configure test that I mentioned is the only place where I noticed a
problem, so as far as I know only the one-byte change I proposed above needs to
be made.
Thanks for the explanation, that makes it clearer now (and possibly my
brain is not as mushed as during my last read/answer).
The code involved here comes directly from gnulib and is not part of the
wget project. The issue affects not only wget and any patching here is
mostly lost time/efford.
So I am adding the gnulib mailing list to the recipients as IMO this
issue should be discussed/answered there. It will be read by people with
more related expertise than I can provide.
Regards, Tim
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 2/2] Implement fallback for explicit_bzero using jump to volatile pointer
> +#else > + void * (* const volatile volatile_memset)(void *, int, size_t) = memset; > + (void) volatile_memset (s, '\0', len); > #endif > } Thanks. I applied this, adding a comment and a gnulib-style ChangeLog entry. Bruno
Re: [PATCH 1/2] Support clang for explicit_bzero
> diff --git a/lib/explicit_bzero.c b/lib/explicit_bzero.c
> index 87fadba81a..71a1cca3b0 100644
> --- a/lib/explicit_bzero.c
> +++ b/lib/explicit_bzero.c
> @@ -56,9 +56,19 @@ explicit_bzero (void *s, size_t len)
>(void) memset_s (s, len, '\0', len);
> #else
>memset (s, '\0', len);
> -# if defined __GNUC__ && !defined __clang__
> - /* Compiler barrier. */
> +# if defined __GNUC__
> +/* Compiler barrier. */
> +# if !defined __clang__
>asm volatile ("" ::: "memory");
> +# else
> + /* See https://bugs.llvm.org/show_bug.cgi?id=15495#c11
> + with asm("" ::: "memory") LLVM analyzes uses of 's'
> + and finds that the whole thing is dead and eliminates it.
> +
> + Using g workarround this problem
> + */
> + __asm__ volatile("" : : "g"(s) : "memory");
> +# endif
> # endif
> #endif
> }
Thanks. I applied this with two changes:
- Make it work also with clang on Windows. Recall that clang on Windows
does not define __GNUC__ [1].
- Use a gnulib-style ChangeLog entry.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2020-08/msg00038.html
[PATCH 1/2] Support clang for explicit_bzero
From: Bastien Roucariès
According to https://bugs.llvm.org/show_bug.cgi?id=15495#c11
llvm need g type constraint
Signed-off-by: Bastien Roucariès
---
lib/explicit_bzero.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/lib/explicit_bzero.c b/lib/explicit_bzero.c
index 87fadba81a..71a1cca3b0 100644
--- a/lib/explicit_bzero.c
+++ b/lib/explicit_bzero.c
@@ -56,9 +56,19 @@ explicit_bzero (void *s, size_t len)
(void) memset_s (s, len, '\0', len);
#else
memset (s, '\0', len);
-# if defined __GNUC__ && !defined __clang__
- /* Compiler barrier. */
+# if defined __GNUC__
+/* Compiler barrier. */
+# if !defined __clang__
asm volatile ("" ::: "memory");
+# else
+ /* See https://bugs.llvm.org/show_bug.cgi?id=15495#c11
+ with asm("" ::: "memory") LLVM analyzes uses of 's'
+ and finds that the whole thing is dead and eliminates it.
+
+ Using g workarround this problem
+ */
+ __asm__ volatile("" : : "g"(s) : "memory");
+# endif
# endif
#endif
}
--
2.29.2
[PATCH 2/2] Implement fallback for explicit_bzero using jump to volatile pointer
From: Bastien Roucariès
Signed-off-by: Bastien Roucariès
---
lib/explicit_bzero.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/explicit_bzero.c b/lib/explicit_bzero.c
index 71a1cca3b0..c39f20164b 100644
--- a/lib/explicit_bzero.c
+++ b/lib/explicit_bzero.c
@@ -54,11 +54,10 @@ explicit_bzero (void *s, size_t len)
explicit_memset (s, '\0', len);
#elif HAVE_MEMSET_S
(void) memset_s (s, len, '\0', len);
-#else
+#elif defined __GNUC__
memset (s, '\0', len);
-# if defined __GNUC__
/* Compiler barrier. */
-# if !defined __clang__
+# if !defined __clang__
asm volatile ("" ::: "memory");
# else
/* See https://bugs.llvm.org/show_bug.cgi?id=15495#c11
@@ -70,5 +69,8 @@ explicit_bzero (void *s, size_t len)
__asm__ volatile("" : : "g"(s) : "memory");
# endif
# endif
+#else
+ void * (* const volatile volatile_memset)(void *, int, size_t) = memset;
+ (void) volatile_memset (s, '\0', len);
#endif
}
--
2.29.2
[V5] explicit_bzero
sorry for that [PATCH 1/2] Support clang for explicit_bzero [PATCH 2/2] Implement fallback for explicit_bzero using jump to
[PATCH 2/2] Implement fallback for explicit_bzero using jump to volatile pointer
From: Bastien Roucariès
Signed-off-by: Bastien Roucariès
---
lib/explicit_bzero.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/explicit_bzero.c b/lib/explicit_bzero.c
index 71a1cca3b0..86a5fd35d7 100644
--- a/lib/explicit_bzero.c
+++ b/lib/explicit_bzero.c
@@ -54,11 +54,10 @@ explicit_bzero (void *s, size_t len)
explicit_memset (s, '\0', len);
#elif HAVE_MEMSET_S
(void) memset_s (s, len, '\0', len);
-#else
+#elif defined __GNUC__
memset (s, '\0', len);
-# if defined __GNUC__
/* Compiler barrier. */
-# if !defined __clang__
+# if !defined __clang__
asm volatile ("" ::: "memory");
# else
/* See https://bugs.llvm.org/show_bug.cgi?id=15495#c11
@@ -70,5 +69,8 @@ explicit_bzero (void *s, size_t len)
__asm__ volatile("" : : "g"(s) : "memory");
# endif
# endif
+#else
+ void * (* const volatile volatile_memset)(void *, int, size_t) = memset;
+ (void) volatile_memset(s, '\0', len);
#endif
}
--
2.29.2
[PATCH 1/2] Support clang for explicit_bzero
From: Bastien Roucariès
According to https://bugs.llvm.org/show_bug.cgi?id=15495#c11
llvm need g type constraint
Signed-off-by: Bastien Roucariès
---
lib/explicit_bzero.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/lib/explicit_bzero.c b/lib/explicit_bzero.c
index 87fadba81a..71a1cca3b0 100644
--- a/lib/explicit_bzero.c
+++ b/lib/explicit_bzero.c
@@ -56,9 +56,19 @@ explicit_bzero (void *s, size_t len)
(void) memset_s (s, len, '\0', len);
#else
memset (s, '\0', len);
-# if defined __GNUC__ && !defined __clang__
- /* Compiler barrier. */
+# if defined __GNUC__
+/* Compiler barrier. */
+# if !defined __clang__
asm volatile ("" ::: "memory");
+# else
+ /* See https://bugs.llvm.org/show_bug.cgi?id=15495#c11
+ with asm("" ::: "memory") LLVM analyzes uses of 's'
+ and finds that the whole thing is dead and eliminates it.
+
+ Using g workarround this problem
+ */
+ __asm__ volatile("" : : "g"(s) : "memory");
+# endif
# endif
#endif
}
--
2.29.2
[V4][0/2] explicit_bzero
Sorry for the late reply Last modification of explicit_bzero
