Bug#993973: nss FTBFS with glibc 2.32: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]
On 2021-09-15 00:06, Aurelien Jarno wrote:
> On 2021-09-09 00:52, Aurelien Jarno wrote:
> > control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=27476
> >
> > On 2021-09-09 00:21, Helmut Grohne wrote:
> > > Source: nss
> > > Version: 2:3.70-1
> > > Severity: serious
> > > Tags: ftbfs
> > > X-Debbugs-Cc: debian-glibc@lists.debian.org
> > >
> > > A native build of nss now fails as follows:
> > >
> > > | x86_64-linux-gnu-gcc -o OBJS/nsinstall.o -c -std=c99 -g -g -fPIC -pipe -ffunction-sections -fdata-sections -DHAVE_STRERROR -DLINUX -Dlinux -Wall -Wshadow -Werror -DXP_UNIX -DXP_UNIX -DDEBUG -UNDEBUG -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DDEBUG -UNDEBUG -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I/<<PKGBUILDDIR>>/dist/include -I/<<PKGBUILDDIR>>/dist/public/coreconf -I/<<PKGBUILDDIR>>/dist/private/coreconf nsinstall.c
> > > | nsinstall.c: In function ‘main’:
> > > | nsinstall.c:70:16: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]
> > > | 70 | #define GETCWD getcwd
> > > | | ^
> > > | nsinstall.c:239:8: note: in expansion of macro ‘GETCWD’
> > > | 239 | cwd = GETCWD(0, PATH_MAX);
> > > | | ^~~~~~
> > > | In file included from nsinstall.c:20:
> > > | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ declared with attribute ‘write_only (1, 2)’
> > > | 520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> > > | | ^~~~~~
> > > | nsinstall.c:70:16: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]
> > > | 70 | #define GETCWD getcwd
> > > | | ^
> > > | nsinstall.c:246:13: note: in expansion of macro ‘GETCWD’
> > > | 246 | todir = GETCWD(0, PATH_MAX);
> > > | | ^~~~~~
> > > | In file included from nsinstall.c:20:
> > > | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ declared with attribute ‘write_only (1, 2)’
> > > | 520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> > > | | ^~~~~~
> > > | cc1: all warnings being treated as errors
> > > | make[2]: *** [../../coreconf/rules.mk:292: OBJS/nsinstall.o] Error 1
> > > | make[2]: Leaving directory '/<<PKGBUILDDIR>>/nss/coreconf/nsinstall'
> > > | make[1]: *** [debian/rules:100: override_dh_auto_build] Error 2
> > > | make[1]: Leaving directory '/<<PKGBUILDDIR>>'
> > > | make: *** [debian/rules:195: build] Error 2
> > > | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> > >
> > > It looks very much like this is due to the glibc 2.32 upload. My reading
> > > of man getcwd is that the call of nss is legit (as a glibc extension).
> > > Maybe this is a glibc bug?
> >
> > This is indeed partially a glibc bug, already reported upstream there:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=27476
> >
> > Note however that the feature of calling getcwd(NULL, >0) is a GNU
> > extension, and that the above code doesn't define _GNU_SOURCE, so this
> > is also a bug in the package.
> >
> > Please also note that there are discussion to deprecate the support of
> > size > 0 when buf is NULL:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26545
>
> I have uploaded a version with a temporary fix, until upstream takes a
> decision. If upstream decides to drop this part of the GNU extension,
> this patch will be removed from the Debian package, so that the
> behaviour is consistent between distribution. Of course in that case
> the documentation will have to be fixed accordingly. The packages using
> this extension will have to get fixed, just like some distributions
> using glibc >= 2.32 started to do.
Note that the patch I submitted has been accepted, so this won't be
reverted.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: