Summary: | x11-libs/motif-2.3.5[-xft]: /.../Xft.h:39:22: fatal error: ft2build.h: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Ulrich Müller <ulm> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jarausch |
Priority: | Normal | Keywords: | UPSTREAM |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | http://bugs.motifzone.com/show_bug.cgi?id=1651 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge-history.txt
environment x11-libs:motif-2.3.5:20160323-234119.log |
Description
Toralf Förster
![]() Created attachment 428920 [details]
emerge-history.txt
Created attachment 428922 [details]
environment
Created attachment 428924 [details]
x11-libs:motif-2.3.5:20160323-234119.log
Looks like this is caused by a spurious lib/Xm/Xm.h in the source tree, which takes precedence over the one in the build tree (which is generated from lib/Xm/Xm.h.in). Xm.h is distributed with the 2.3.5 tarball (presumably it shouldn't, and it wasn't with 2.3.4). Removing lib/Xm/Xm.h in src_prepare works around it. No revbump because it is a build-time failure. Thank you for reporting. Posting a snippet from #gentoo-qa for reference: <ulm> mgorny: I have a question to the master of multilib and out-of-tree builds :) <ulm> in a nutshell, a package come with a foo.h.in file from which foo.h is generated via AC_CONFIG_HEADERS <mgorny> sounds normal s ofar <ulm> now the tarball contains both foo.h.in and foo.h <ulm> so there will be a foo.h both in the source tree and in the build tree <ulm> and depending on order of -I options, the sources get the one from the source tree, which is wrong <ulm> and of course this is no problem for in-tree builds <ulm> because the file gets just overwritten by configure there <ulm> now, what's the proper way to handle this? just remove foo.h from the source tree, e.g. in src_prepare? <ulm> doing this looks a bit clumsy to me <ulm> OTOH, "make clean" or the like obviously won't work <ulm> (well, it would work if done upstream before creating the tarball) <floppym> I think the proper solution would be not to ship a file which is generated by configure in the source tarball. <ulm> obviously :) <ulm> the question is how to handle this downstream <floppym> I think you've given the valid options: reorder the -I params, or remove the file. <floppym> The latter sounds easier, so I would do that personally. [...] <floppym> ulm: Generally make dist should take care of including the correct files. <floppym> Unless they have Makefile.am configured wrong. [...] <ulm> hm, the tarball created by make dist contains the bad header file <floppym> Yeah, so somewhere that header file is being treated as a primary source file in Makefile.am, or they have it in EXTRA_DIST. <ulm> all files in xm_HEADERS in Makefile.am would qualify as sources, right? <ulm> yeah, there should be an extra nodist_xm_HEADERS for the generated ones So it is a problem of lib/Xm/Makefile.am which I shall report upstream. *** Bug 578176 has been marked as a duplicate of this bug. *** |