Closed listout closed 1 month ago
I think the error is fixed in newer gnulib
Thanks for the report and fix. I've updated gnulib in mmv git; please can you test whether that fixes your problem?
Checking, thank for the fast reply!
I will state for the record, it is unlikely to fix anything given that gnulib hasn't changed free.c or free.m4 other than to update the copyright dates, within the submodule bump you made.
Moreover, the gnulib implementation of free() looks inherently broken. It detects this as a reason to reject the libc version of free:
checking whether free is known to preserve errno... no
and as a result, it uses the following where HAVE_FREE_POSIX is detected as false:
/* A function definition is only needed if HAVE_FREE_POSIX is not defined. */
#if !HAVE_FREE_POSIX
# include <errno.h>
void
rpl_free (void *p)
# undef free
{
# if defined __GNUC__ && !defined __clang__
/* An invalid GCC optimization
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396>
would optimize away the assignments in the code below, when link-time
optimization (LTO) is enabled. Make the code more complicated, so that
GCC does not grok how to optimize it. */
int err[2];
err[0] = errno;
err[1] = errno;
errno = 0;
free (p);
errno = err[errno == 0];
# else
int err = errno;
free (p);
errno = err;
# endif
}
#endif
Note how it undefines free, then uses it (to get at the standard library version with wrapping?)
The actual check "whether free() is POSIX" is great, by the way:
#include <stdlib.h>
int
main (void)
{
#if 2 < __GLIBC__ + (33 <= __GLIBC_MINOR__)
#elif defined __OpenBSD__
#elif defined __sun
#else
#error "'free' is not known to preserve errno"
#endif
;
return 0;
}
Thanks, @eli-schwartz, I'll file an issue with gnulib.
The gnulib maintainers suggest that this may be something to do with libgc. But, I recently removed the use of libgc. @listout, are you compiling from git, or the most recent release?
I see that the Gentoo bug report is for version 2.5.1 of mmv. I have recently removed the use of libgc, precisely because it is hard to use it as I did with an unmodified code base and #define
trickery.
So, please can you try building current git and let me know whether there's still a problem? The gnulib maintainers test on Alpine Linux with musl and there's no problem there with the free
module, I am informed.
I usually find gnulib fairly confusing so probably the easiest way for me to test would be if someone could provide a source tarball that contains the requisite gnulib snippets copied in.
@eli-schwartz the instructions in README
should be clear; please file an issue if not.
I've made a new release that does not use libgc. If there is still a problem, please either reopen this issue or file a new one, as appropriate.
I confirm that the 2.7 tarball builds fine for musl.
While building on musl lib I get an error
I believe this is due to gnulib?
For full further reference please see https://bugs.gentoo.org/935241