Trying to build `khtml` I've faced w/ the error (see below). Brief investigation discovers that `/usr/include/gif_lib.h` has its own external declaration for `reallocarray` which is conflicts w/ `/usr/include/stdlib.h` (came from `glibc-2.26`), so when this header gets `#included` into a C++ project (like `khtml`) the following error has happened... Reproducible: Always Actual Results: In file included from /storage/tmp/paludis/kde-frameworks-khtml-5.40.0/work/khtml-5.40.0/src/imload/decoders/gifloader.cpp:44:0: /usr/include/gif_lib.h:248:51: error: declaration of 'void* reallocarray(void*, size_t, size_t)' has a different exception specifier reallocarray(void *optr, size_t nmemb, size_t size); ^ In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/cstdlib:72:0, from /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/stl_algo.h:59, from /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/algorithm:62, from /usr/include/qt5/QtCore/qglobal.h:109, from /usr/include/qt5/QtCore/qatomic.h:41, from /usr/include/qt5/QtCore/qrefcount.h:43, from /usr/include/qt5/QtCore/qbytearray.h:44, from /usr/include/qt5/QtCore/QByteArray:1, from /storage/tmp/paludis/kde-frameworks-khtml-5.40.0/work/khtml-5.40.0/src/imload/imageloaderprovider.h:28, from /storage/tmp/paludis/kde-frameworks-khtml-5.40.0/work/khtml-5.40.0/src/imload/decoders/gifloader.h:4, from /storage/tmp/paludis/kde-frameworks-khtml-5.40.0/work/khtml-5.40.0/src/imload/decoders/gifloader.cpp:27: /usr/include/stdlib.h:443:14: error: from previous declaration 'void* reallocarray(void*, size_t, size_t) throw ()' extern void *reallocarray (void *__ptr, size_t __nmemb, size_t __size) ^
Created attachment 504456 [details, diff] The patch to fix compile error for the mentioned case It removes the incorrect declaration and use `stdlib.h` instead.
Shouldn't the patch also remove this function's declaration in the giflib's code, not only from the header?
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #2) > Shouldn't the patch also remove this function's declaration in the giflib's > code, not only from the header? Hmmm, that is the interesting question... From one POV it doesn't break anything. As far as I see, the implementation has taken from OpenBSD (which is the origin of this function even in GNU libc). Since ABI is matching -- everything would be fine. In fact, this symbol even exported by the built `libgif.so`, so in theory it could be chosen by `ld` over libc's export (depending on some circumstances)... but again, until the implementation is sane, everything would be fine. To fix it properly, a new test needs to be added to the `configure.ac` to check if the function not availabe, then use their own implementation... but it is better to address to upstream. (it is quite easy in fact, but I can't do it now cuz have insufficient time)
Is there a bug we can track upstream?
(In reply to Andreas Sturmlechner from comment #4) > Is there a bug we can track upstream? Nope
this happened to me too, placing the patch in /etc/portage/patches/../giflib/ to compile khtml and continue the upgrade.
i've filed a bug upstream. even if the system doesn't provide the func, giflib shouldn't be exporting it as it isn't a standard gif related symbol. in the mean time we prob want to give it hidden visibility and rename it to avoid clashes.
There is a patch for this in 5.1.4-r1 by now from bug #637438. Unfortunately, there seem to be some issues with it, see bug #651820. If you want to help evaluate the two candidates to go forward, please join at bug #651820. I'll close this report as the conflicting declaration has been resolved.