media-gfx/swftools-0.7.0 has this.. DEPEND=">=media-libs/t1lib-1.3.1 and on ~x86 system, during configure: *************************************************** * The following headers/libraries are missing: t1lib ungif avifile * Disabling avi2swf tool... * Disabling gif2swf tool... *************************************************** and on x86 system, during configure: *************************************************** * The following headers/libraries are missing: ungif avifile * Disabling avi2swf tool... * Disabling gif2swf tool... *************************************************** Point is, on x86 it finds the installed media-libs/t1lib-5.0.2 but on ~x86 system it doesn't. - It can't find libungif which I think, is not in portage anymore. - It can't find avifile which I think, is not in portage anymore. So there is 3 issues with libraries it needs resulting at least 2 missing commands, gif2swf and avi2swf (and to repeat myself, this is IMO the most important feature of this package). 0.7.0 was just marked stable, and I don't really understand how this can be since major features is missing. See bug, http://bugs.gentoo.org/show_bug.cgi?id=135393 for more comments. (Personally, I'd dump the whole swftools from portage if those missing libraries isn't added to portage tree as it renders swftools.. almost unusable.) Apologies if i've used too rude statements but I'm having hard time understanding why it isn't in package.mask instead of stable x86!)
Adding tsunam to CC because I'm hoping a comment from him.
avi2swf and gif2swf support won't be there, sorry. libungif was colliding w/ giflib, causing nightmares for everyone, and avifile is broken beyond any repair and won't be coming back, ever. Post emerge -pv t1lib output from both systems (i.e., the working and non-working one and reopen then).
Created attachment 88662 [details, diff] swftools-0.7.0.ebuild.patch , adds ewarn with epause to swftools-0.7.0.ebuild about missing features. about t1lib, on ~x86 [ebuild R ] media-libs/t1lib-5.0.2 USE="X -doc" 0 kB on x86 [ebuild R ] media-libs/t1lib-5.0.2 +X -doc 0 kB
Reopening because of the patch to ebuild to inform users about lack of functionality of this package and for asked info.
Please, don't use echo in ebuilds, that's what einfo if for. And that epause is pretty pointless and annoying. As for this bug, I assume that t1lib is broken on your ~x86 box, you should re-emerge it. No reason why swtfools should detect an identical t1lib version on one system and not on the other.
(In reply to comment #5) > Please, don't use echo in ebuilds, that's what einfo if for. And that epause is > pretty pointless and annoying. > Roger, posting another fix and obsoliting the old one. > As for this bug, I assume that t1lib is broken on your ~x86 box, you should > re-emerge it. No reason why swtfools should detect an identical t1lib version > on one system and not on the other. Did that, no change -- still doesn't find t1lib.
Created attachment 88671 [details, diff] Cleaned patch to swftools-0.7.0.ebuild , thanks to jakub.
After taking a real close look at this, summary: - swftools-0.7.0 doesn't find t1lib because of LDFLAGS="-Wl,--as-needed" - gif2swf and avi2swf doesn't get installed because of libraries which isn't in portage, and will not be added in portage. einfo patch in ebuild should take care of this.
Thanks, I added a slightly reworded einfo to the ebuild.
(In reply to comment #9) > Thanks, I added a slightly reworded einfo to the ebuild. > I'm reopening because the LDFLAGS="-Wl,--as-needed" issue with t1lib can't be found during configure is still there and this is depending on --as-needed tracker. I included more than one issue to this bug which might've been confusing, sorry about that.. Thanks, drac
Comment on attachment 88671 [details, diff] Cleaned patch to swftools-0.7.0.ebuild , thanks to jakub. allready in tree.
That problem is related to t1lib itself, not to swftool.
(In reply to comment #12) > That problem is related to t1lib itself, not to swftool. > Right, you are correct. Patch in t1lib bug for --as-needed, https://bugs.gentoo.org/show_bug.cgi?id=130362#c3 fixes also this bug.
