Summary: | media-libs/giflib-5.1.4 conflicting declaration for `reallocarray` | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alex Turbov <I.zaufi> |
Component: | Current packages | Assignee: | Gentoo Graphics Project <graphics+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://sourceforge.net/p/giflib/bugs/110/ | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=637438 https://bugs.gentoo.org/show_bug.cgi?id=651820 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | The patch to fix compile error for the mentioned case |
Description
Alex Turbov
2017-11-15 20:17:05 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.
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. |