| Summary: | media-libs/imlib-1.9.14-r2 does not build with USE=-gif | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sascha Silbe <sascha-gentoo-bugzilla> |
| Component: | Current packages | Assignee: | Mamoru KOMACHI (RETIRED) <usata> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | exg, gnome, holler.loudly, james.kyte, jonathan.huot |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Build log | ||
|
Description
Sascha Silbe
2004-09-12 12:21:58 UTC
Created attachment 39457 [details]
Build log
The problem comes from the following two lines in src_install of giflib-4.1.3.ebuild:
# if gif is not in USE, then ungif is preferred
use gif || rm -rf "${D}/usr/bin" "${D}/usr/include/gif_lib.h"
(libungif has
use gif && rm -rf "${D}/usr/bin" "${D}/usr/include/gif_lib.h"
)
The header removal trickery might have to do with bug 18820.
As a temporary workaround, one can do
USE="+gif" emerge --oneshot giflib
and imlib should see the missing header afterwards.
I ran into this problem too. (Just a vote for fix). Re-assigning to gnome-team, as I'm not able to maintain this. *** Bug 73754 has been marked as a duplicate of this bug. *** Strange, but after emerging giflib again, imlib installed fine. emerging giflib again didn't worked for me but using USE="+gif" emerge --oneshot giflib did the truque, thanx. I had the exact same problem despite the fact that I did not have "-gif" in my use line. giflib was installed, but re-emerging it did the trick, just like <a href="#c6">comment 6</a> *** Bug 80252 has been marked as a duplicate of this bug. *** *** Bug 83284 has been marked as a duplicate of this bug. *** Maybe the ebuild needs another dependancy? The Readme says: "Imlib1 now *REQUIRES* libjpeg, libpng, libtiff, and libgif/libungif. If you do not have these libraries, Imlib1 will *NOT* compile." So if it needs both libgif and libungif both should be included in the dependancies. This way even in case you got -gif set it will be possible to emerge imlib. Later Sebastian Sorry, I think I was mistaken. They seem to mean giflib OR libungif. The weired thing is I got libgif already on my box (so it must have compiled fine before) and now it hangs while I'm doing -e world. Anyway. Maybe it's the giflib ebuild that started all the confusion because it has a "gif" USE-flag itself? Yeah, I think the gif USE flag is indeed confusing. use.desc says "gif - Adds GIF image support". The giflib ebuild says "# if gif is not in USE, then ungif is preferred
use gif || rm -r "${D}"/usr/bin "${D}"/usr/include/gif_lib.h"
Adding gif image support and preferring libungif are two different things combined in one USE flag. And as we just saw this can break things.
Maybe giflib should have a USE-flag "libungif" instead?
Sebastian
usata, looks like you last touched libgif, could you have a look at the last few comments and the problem in general ? Right, giflib and libungif use "gif" USE flag a bit different from what is written in use.desc. I touched the ebuilds to make it compile on ppc-macos. (because both provided /usr/include/gif_lib.h, which means you cannot install both on collision-protect enabled system) We are going to remove libungif from the tree, so I think we can remove gif USE flag from both ebuilds and use /usr/include/gif_lib.h from giflib. Fixed in giflib-4.1.3-r1 and libungif-4.1.3-r1. (some packages still depend on libungif, so I had to make libungif-4.1.3-r1, even though we'll remove libungif in the future) *** Bug 104368 has been marked as a duplicate of this bug. *** *** Bug 105739 has been marked as a duplicate of this bug. *** |
