Summary: | >=media-libs/freetype-2.5.3-r1[fontforge]: cvdebug.c:62:33: fatal error: internal/internal.h: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dani Church <dani.church> |
Component: | [OLD] Library | Assignee: | Ben de Groot (RETIRED) <yngwin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dani.church, david.w.noon, fonts, polynomial-c |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
freetype-2.5.3-r1.ebuild
freetype-2.5.5 build log fontforge-20120731-r1 build log Patch to freetype-2.5.5.ebuild to fix issue Patch to freetype-2.6.2.ebuild to fix issue again |
Description
Dani Church
2014-08-14 18:29:11 UTC
Created attachment 382904 [details]
freetype-2.5.3-r1.ebuild
Working ebuild for freetype.
Please attach the entire build log to this bug report. Comment on attachment 382904 [details]
freetype-2.5.3-r1.ebuild
--- freetype-2.5.3-r1.ebuild 2014-08-04 12:19:42.407871052 +0200
+++ - 2014-08-15 10:09:52.524834398 +0200
@@ -148,7 +148,7 @@
# Probably fontforge needs less but this way makes things simplier...
einfo "Installing internal headers required for fontforge"
local header
- find src/truetype include/freetype/internal -name '*.h' | \
+ find src/truetype include/internal -name '*.h' | \
while read header; do
mkdir -p "${ED}/usr/include/freetype2/internal4fontforge/$(dirname ${header})" || die
cp ${header} "${ED}/usr/include/freetype2/internal4fontforge/$(dirname ${header})" || die
As a developer for the FontForge fork Sorts Mill Tools, I am encountering the same problem in my development work. (I do not employ USE=fontforge in other ebuilds, myself.) This is still an issue. Attaching build logs for freetype and fontforge. Created attachment 396102 [details]
freetype-2.5.5 build log
Created attachment 396104 [details]
fontforge-20120731-r1 build log
Created attachment 396106 [details, diff]
Patch to freetype-2.5.5.ebuild to fix issue
I am still seeing this error with media-gfx/fontforge-20150430. The freetype upstream, not being able to make up their minds, have changed the include structure to restore the freetype/ layer of the include hierarchy: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/include/freetype/internal?id=392cf22f8a5a281b8ebc56bf932e66da78f66410 As a result, our recent freetype ebuilds are failing again in exactly the same way as before. The fix is to revert the change from attachment 396106 [details, diff]. Created attachment 423396 [details, diff]
Patch to freetype-2.6.2.ebuild to fix issue again
What if you just did find src/truetype include/internal include/freetype/internal -name '*.h' and it should be safe at least for a while? (In reply to Mikael Magnusson from comment #12) > What if you just did > find src/truetype include/internal include/freetype/internal -name '*.h' > and it should be safe at least for a while? Unless they make a habit of switching their sourcetree around a lot, I think that's probably overengineering for a problem that doesn't exist. what is the state of this with 2.6.3-r1? (In reply to Pacho Ramos from comment #14) > what is the state of this with 2.6.3-r1? Needs the same patch as 2.6.2, from comment #11. commit 5b6d98096fe22f5fe9cec1eb6194fcb9147b650b Author: Lars Wendler <polynomial-c@gentoo.org> Date: Mon May 30 09:07:49 2016 media-libs/freetype: Fixed header installation for fontforge (#519934) Package-Manager: portage-2.2.28 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Fixed in =media-libs/freetype-2.6.3-r1. Sorry for the long wait. |