| Summary: | app-text/ghostscript-gpl does not parallel-build (forces MAKEOPTS=-j1) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mart Raudsepp <leio> |
| Component: | [OLD] Printing | Assignee: | Printing Team <printing> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | kanelxake, wonko |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Patch to add dependency so that ijs.$(OBJ) is not built until its prerequisite tools are available
Patch to ebuild to apply attachment #192988 and adjust base/zlib.mak ghostscript-gpl-8.70-parallel-build.patch Patch to fix djvu build failure |
||
|
Description
Mart Raudsepp
2008-08-10 14:21:27 UTC
Created attachment 192988 [details, diff]
Patch to add dependency so that ijs.$(OBJ) is not built until its prerequisite tools are available
This package has multiple issues with parallel make. The first, which is easy to fix, is that ijs.$(OBJ) uses the program named by $(ECHOGS_XE), but does not depend on it, so make may try to run the program before it was built. This patch adds a dependency to prevent that. This patch can go upstream easily enough.
Additionally, the package needs four rules from base/zlib.mak to be present, but some of the other rules in base/zlib.mak cause a parallel make to react badly to the ebuild removing the bundled zlib directory. I will attach a patch to the ebuild which cleans base/zlib.mak of all but the necessary rules. I doubt upstream will take this, since it probably breaks building the bundled zlib. I have not investigated why a non-parallel make succeeds with the full zlib.mak present.
Created attachment 192991 [details, diff] Patch to ebuild to apply attachment #192988 [details, diff] and adjust base/zlib.mak With this patch and the preceding one applied, I am able to build ghostscript with MAKEOPTS=-j10. This patch does not address the parallel install issue documented in bug #251066. Hi Kevin and thanks for the patches, I considered the fix for the 8.70 bump but then realized that it doesn't build with USE="djvu". Attached is the patch I used. Created attachment 200207 [details, diff]
ghostscript-gpl-8.70-parallel-build.patch
Created attachment 242573 [details, diff]
Patch to fix djvu build failure
This patch is against gsdjvu-1.4 for use with USE="djvu". It fixes parallell build failure. Please apply.
Sent upstream.
After applying the patch from Timo Gurr and my patch to the ghostscript-gpl-8.71-r5 ebuild it succeded to build with the following USE-flags:
[ebuild R ] app-text/ghostscript-gpl-8.71-r5 USE="X cairo cups djvu gtk jpeg2k -bindist" LINGUAS="-ja -ko -zh_CN -zh_TW" 0 kB [1]
And PLEASE apply these patches, as genlop is my witness they do a difference!
For these outputs where the first and third is with old ebuild, and second and fourth is with patches running -j10 on a Core 7i, 4 cores and hyperthread:
Sat Jul 31 18:25:47 2010 >>> app-text/ghostscript-gpl-8.71-r5
merge time: 5 minutes and 8 seconds.
Thu Aug 12 16:07:20 2010 >>> app-text/ghostscript-gpl-8.71-r5
merge time: 1 minute and 52 seconds.
Thu Aug 12 16:14:22 2010 >>> app-text/ghostscript-gpl-8.71-r5
merge time: 4 minutes and 59 seconds.
Thu Aug 12 16:16:13 2010 >>> app-text/ghostscript-gpl-8.71-r5
merge time: 1 minute and 49 seconds.
Yes, that is true, the merge-time more then halved, I had to redo the merges only to confirm.
(In reply to comment #5) > Created an attachment (id=242573) [details] > Patch to fix djvu build failure > > This patch is against gsdjvu-1.4 for use with USE="djvu". It fixes parallell > build failure. Please apply. > > Sent upstream. > This patch is now incorporated upstream. Is there any bug for upstream ghostscript to fix the remaining issues? Version in question was removed from the tree (In reply to comment #8) > Version in question was removed from the tree Versions are arbitrary labels. Don't confuse them with bug fixes. *** Bug 430946 has been marked as a duplicate of this bug. *** Removing the gs version in $summary, this needs to get fixed upstream. I'll open an upstream bug report if time permits and we'll see if we can get Kevin Pyle's fixes upstreamed if they still fix the issue for >=9.06. If anyone has some spare time to produce a proper patch/diff, test it against the recent gs version and report it upstream in the meantime, feel free to do so (if you do so be sure to add a link to the upstream bug in $URL here so we can track the progress, thanks!). Usually the gs upstream developers are very responsive and appreciate any patches. This issue seems to be finally fixed somewhere in between 9.10 and 9.15. I dropped "-j1" for 9.15* *ghostscript-gpl-9.10-r4 (09 Nov 2014) *ghostscript-gpl-9.15-r1 (09 Nov 2014) 09 Nov 2014; Matthias Maier <tamiko@gentoo.org> +ghostscript-gpl-9.10-r4.ebuild, +ghostscript-gpl-9.15-r1.ebuild, -ghostscript-gpl-9.10-r3.ebuild, -ghostscript-gpl-9.14.ebuild, -ghostscript-gpl-9.15.ebuild: also install [...]/Resource/Font/* wrt bug #490248, enable parallel make for 9.15* wrt bug #234378 (In reply to Matthias Maier from comment #12) > This issue seems to be finally fixed somewhere in between 9.10 and 9.15. I > dropped "-j1" for 9.15* Unfortunately, it doesn't seem to be the case: bug 550926 |