Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 637636 - media-libs/giflib-5.1.4 conflicting declaration for `reallocarray`
Summary: media-libs/giflib-5.1.4 conflicting declaration for `reallocarray`
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Graphics Project
URL: https://sourceforge.net/p/giflib/bugs...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-15 20:17 UTC by Alex Turbov
Modified: 2018-03-30 19:44 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
The patch to fix compile error for the mentioned case (giflib-5.1.4-use-stdlib-4-reallocarray.patch,733 bytes, patch)
2017-11-15 20:18 UTC, Alex Turbov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Turbov 2017-11-15 20:17:05 UTC
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)
              ^
Comment 1 Alex Turbov 2017-11-15 20:18:28 UTC
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.
Comment 2 Vadim A. Misbakh-Soloviov (mva) (RETIRED) gentoo-dev 2017-11-16 11:24:14 UTC
Shouldn't the patch also remove this function's declaration in the giflib's code, not only from the header?
Comment 3 Alex Turbov 2017-11-16 22:04:48 UTC
(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)
Comment 4 Andreas Sturmlechner gentoo-dev 2017-11-18 22:37:03 UTC
Is there a bug we can track upstream?
Comment 5 Alex Turbov 2017-11-24 11:51:16 UTC
(In reply to Andreas Sturmlechner from comment #4)
> Is there a bug we can track upstream?

Nope
Comment 6 Kash Pande 2017-12-16 23:33:51 UTC
this happened to me too, placing the patch in /etc/portage/patches/../giflib/ to compile khtml and continue the upgrade.
Comment 7 SpanKY gentoo-dev 2018-01-30 03:45:14 UTC
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.
Comment 8 Sebastian Pipping gentoo-dev 2018-03-30 19:44:03 UTC
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.