Summary: | dev-dotnet/libgdiplus-3.12: too few arguments to function 'EGifCloseFile' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Erik Zeek <zeekec> |
Component: | Current packages | Assignee: | dotnet project <dotnet> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | anton.kochkov, che, gentoo, gmt, jhyeon, mark+gentoobugs, noein93, owmcclung, rose, thanasis, xaviermiller |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 451324 | ||
Attachments: |
Build log.
giflib.patch libgdiplus-3.12-giflib-quantizebuffer.patch |
Description
Erik Zeek
2016-01-12 02:47:32 UTC
I confirm it, I have the same error. Created attachment 422656 [details, diff]
giflib.patch
Created attachment 422658 [details, diff]
libgdiplus-3.12-giflib-quantizebuffer.patch
I had the same. After applying the attached giflib.patch, the libgdiplus-3.12-giflib-quantizebuffer.patch failed to apply, so I had to change some details in it. With these two, libgdiplus compiled fine for me. I'm no developer, just fiddled a bit around to get it to compile. These two bugs (this and https://bugs.gentoo.org/show_bug.cgi?id=571642) are the same, they both are caused by this package not being updated for libgif 5.x. I managed to write a patch on my system successfully, without needing to worry about updating the quantizebuffer patch file, so I'm not sure what went wrong for daniel. However, it's preferred to update libgdiplus to a version that does support libgif 5.x properly without writing the patch ourselves. What a PITA. OK I wanted the following cake: o not to think about this very much o to have this ebuild compile o to use upstream portage's ebuild Eating it was less important to me but also preferably: o to generate a working library or at the very least o not to knowingly have generated a non-working library So I implemented all of daniel's advice by applying the following patch from post_src_prepare in /etc/portage/env/dev-dotnet/libgdiplus-3.12: http://pastebin.com/NUiVjsPx I have a really ugly bashrc that implements epatch-user-like semantics in nonstandard places for shit like this: /etc/portage/env/epatchuser-post_src_prepare: GMT_EPATCH_USER_FORCE=yes GMT_EPATCH_USER_POST_SRC_PREPARE=yes and, here is the really disgusting part: /etc/portage/bashrc (abridged): http://pastebin.com/ahCGUy2y Not so sure how well I captured the relevant logic and filtered the irrelevant logic from my bashrc, it's a real damn mess. but if someone "just wants to cut and paste something" that might do it if you know how to use it. hth :/ I'm not necessarily endorsing daniel's solution -- not that I see any problem with it, I've simply not given any thought whatsoever to underlying causes, correctness at runtime, upstream maintainership, code style, compatibility with stable keywords, and so on, so all I can really say is this makes the ebuild compile on my box): *** Bug 571642 has been marked as a duplicate of this bug. *** Like I said in the other bug, we need to add libgdiplus-4.2 to portage. That version compiles with giflib-5 Here is a proposed ebuild for 4.2: https://github.com/gentoo/gentoo/pull/673 merged to tree, synced overlay, thanks for patch and notification |