Bug#1109256: libkpathsea-dev: redeclares Standard C functions with incompatible prototype, causing FTBFS elsewhere
Control: tags -1 + patch pending On 14.07.25 11:03, Simon McVittie wrote: Hello Simon, I think should do something more like this (pseudo-patch, untested) so that it treats __STDC__ as implying that every Standard C header is present: After applying two patches from upstream, which basically remove these function declarations, I can build evince using gcc-15. Tagging. Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1109256: libkpathsea-dev: redeclares Standard C functions with incompatible prototype, causing FTBFS elsewhere
On 14.07.25 Simon McVittie ([email protected]) wrote: Hello, > In #1096597, Matthias Klose reported that evince FTBFS with gcc-15 as > default (it is not the default for trixie, but will become the default > in forky). This seems to be caused by libkpathsea-dev's headers, > combined with gcc-15 defaulting to C23. > > As an example of the class of issue I'm reporting, libkpathsea-dev's > c-std.h has this: > I've got a patch from Karl. New packages are on [1]. Are you willing to test? Hilmar [1] https://people.debian.org/~hille42/1109256/ signature.asc Description: PGP signature
Bug#1109256: libkpathsea-dev: redeclares Standard C functions with incompatible prototype, causing FTBFS elsewhere
On 14.07.25 Norbert Preining ([email protected]) wrote: Hello Norbert, > AFAIR one needs to pass > -std=gnu17 > which should suffice. > > Best regards > I agree here with Simon. Forcing another package to lower the standards, just b/c TL introduce incompatible function declarations (this is what I understood happened) is at least not a good style. I'll try to contact Karl for this. No, he won't be excited. ;) It is a workaround, one could accept until there is a solution. Hilmar signature.asc Description: PGP signature
Bug#1109256: libkpathsea-dev: redeclares Standard C functions with incompatible prototype, causing FTBFS elsewhere
On Mon, 14 Jul 2025 at 23:10:21 +0900, Norbert Preining wrote: AFAIR one needs to pass -std=gnu17 which should suffice. I think that would be another viable workaround, but ideally dependent packages like evince shouldn't need to know and hard-code "my dependencies aren't C23-compatible" because that scales pretty badly, so I'd prefer to leave this bug open. (For forky - like the original FTBFS report, I'm certainly not asking for anything to change here for trixie!) I suspect this could also be an issue if anything is using libkpathsea from C++ code, which has the C23-like interpretation of the meaning of a declaration with no arguments. smcv
Bug#1109256: libkpathsea-dev: redeclares Standard C functions with incompatible prototype, causing FTBFS elsewhere
AFAIR one needs to pass -std=gnu17 which should suffice. Best regards Norbert On Mon, 14 Jul 2025, Simon McVittie wrote: > Package: libkpathsea-dev > Version: 2024.20240313.70630+ds-6 > Severity: important > Tags: ftbfs upstream forky sid > Control: block 1096597 by -1 > Control: affects -1 + src:evince > > In #1096597, Matthias Klose reported that evince FTBFS with gcc-15 as > default (it is not the default for trixie, but will become the default > in forky). This seems to be caused by libkpathsea-dev's headers, > combined with gcc-15 defaulting to C23. > > As an example of the class of issue I'm reporting, libkpathsea-dev's > c-std.h has this: > > >#ifdef HAVE_STDLIB_H > >#include > >/* Include before , to help avoid NULL > > redefinitions on some systems. (We don't include > > ourselves any more, but FYI.) */ > >#else > >/* It's impossible to say for sure what the system will deign to put in > > , but let's hope it's at least this. */ > >extern char *getenv (); > >#endif /* not HAVE_STDLIB_H */ > > and evince includes followed by . > > The code in c-std.h assumes that the build system of every dependent > package will check for stdlib.h and define HAVE_STDLIB_H if found, but > there is a tendency to stop doing that, and instead assume that all > platforms comply with a 1989 C standard by now. In particular Evince > does not check for , and includes it unconditionally (I > assume). > > In C11 or older, `extern char *getenv ()` declares getenv() as a > function taking unspecified parameters and returning a string, but in > C23 it declares getenv() as a function taking *no* parameters and > returning a string, hence the compiler sees this as a declaration that > is incompatible with the one it already saw in , and errors > out: > > >/usr/include/kpathsea/c-std.h:48:14: error: conflicting types for ‘getenv’; > >have ‘char *(void)’ > > 48 | extern char *getenv (); > > | ^~ > > An equivalent failure mode is seen in the evince build log for other > Standard C functions like strtok() and strstr(). There might be others, > I didn't inspect all of the kpathsea headers. > > evince could presumably work around this by conditionally or > unconditionally defining HAVE_STDLIB_H, etc., before it includes > kpathsea headers; but it shouldn't have to, because each library should > be self-contained. > > I think should do something more like this > (pseudo-patch, untested) so that it treats __STDC__ as implying that > every Standard C header is present: > > -#ifdef HAVE_STDLIB_H > +#if defined(__STDC__) || defined(HAVE_STDLIB_H) > #include > ... > > (or it could check __STDC_VERSION__ if preferred) > > ... or it could just assume that every platform has Standard C headers > by now, since C89 is several decades old. > > Thanks, > smcv > -- DI Dr Norbert Preininghttps://www.preining.info arXiv / Cornell University + IFMGA Guide + TU Wien + TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#1109256: libkpathsea-dev: redeclares Standard C functions with incompatible prototype, causing FTBFS elsewhere
Package: libkpathsea-dev Version: 2024.20240313.70630+ds-6 Severity: important Tags: ftbfs upstream forky sid Control: block 1096597 by -1 Control: affects -1 + src:evince In #1096597, Matthias Klose reported that evince FTBFS with gcc-15 as default (it is not the default for trixie, but will become the default in forky). This seems to be caused by libkpathsea-dev's headers, combined with gcc-15 defaulting to C23. As an example of the class of issue I'm reporting, libkpathsea-dev's c-std.h has this: >#ifdef HAVE_STDLIB_H >#include >/* Include before , to help avoid NULL > redefinitions on some systems. (We don't include > ourselves any more, but FYI.) */ >#else >/* It's impossible to say for sure what the system will deign to put in > , but let's hope it's at least this. */ >extern char *getenv (); >#endif /* not HAVE_STDLIB_H */ and evince includes followed by . The code in c-std.h assumes that the build system of every dependent package will check for stdlib.h and define HAVE_STDLIB_H if found, but there is a tendency to stop doing that, and instead assume that all platforms comply with a 1989 C standard by now. In particular Evince does not check for , and includes it unconditionally (I assume). In C11 or older, `extern char *getenv ()` declares getenv() as a function taking unspecified parameters and returning a string, but in C23 it declares getenv() as a function taking *no* parameters and returning a string, hence the compiler sees this as a declaration that is incompatible with the one it already saw in , and errors out: >/usr/include/kpathsea/c-std.h:48:14: error: conflicting types for ‘getenv’; >have ‘char *(void)’ > 48 | extern char *getenv (); > | ^~ An equivalent failure mode is seen in the evince build log for other Standard C functions like strtok() and strstr(). There might be others, I didn't inspect all of the kpathsea headers. evince could presumably work around this by conditionally or unconditionally defining HAVE_STDLIB_H, etc., before it includes kpathsea headers; but it shouldn't have to, because each library should be self-contained. I think should do something more like this (pseudo-patch, untested) so that it treats __STDC__ as implying that every Standard C header is present: -#ifdef HAVE_STDLIB_H +#if defined(__STDC__) || defined(HAVE_STDLIB_H) #include ... (or it could check __STDC_VERSION__ if preferred) ... or it could just assume that every platform has Standard C headers by now, since C89 is several decades old. Thanks, smcv
