1) print/pdftk build has been broken since gcj was removed from lang/gcc42. 2) gcj from both lang/gcc44 and lang/gcc45 is lacking ecj1 (ecj.jar) Fix: Not sure yet. We might need to bring java/ecj-bootstrap back. How-To-Repeat: Update ports tree. Rebuild lang/gcc42 to make sure. Then, try to build print/pdftk.
Responsible Changed From-To: freebsd-ports-bugs->glarkin Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=140783 Date: Sun, 22 Nov 2009 19:55:00 +0100 (CET)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Thanks for the report and sorry for the breakage. Greg and me have been > made aware of this by pointyhat, and my best suggestion right now is to > employ USE_GCC=4.4+ instead of USE_GCC=4.2+ which I believe should address > this. > > I am also wondering whether we do want something like USE_GCC=java or > such that makes this kind of dependency more transparent. > > Gerald Hi Gerald, It would be great if bsd.gcc.mk supported very finely-grained USE flags like so (rough idea): USE_GCC_VER=4.3+ USE_GCC_FEATURE=c++ objc java fortran Of course, based on your recent commits, not all combinations of the two USE options above would be valid. Would it be difficult to detect invalid combinations in bsd.gcc.mk and emit errors? Thank you, Greg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLDDx90sRouByUApARArT9AJsFyTbSYb3uudCc326XvBrqTDCYHQCeKOer zCNUaSHRdP1cIwCi9qTBKtc= =GQ2p -----END PGP SIGNATURE-----
On Tue, 24 Nov 2009, Greg Larkin wrote: > It would be great if bsd.gcc.mk supported very finely-grained USE flags > like so (rough idea): > > USE_GCC_VER=4.3+ > USE_GCC_FEATURE=c++ objc java fortran > > Of course, based on your recent commits, not all combinations of the two > USE options above would be valid. Would it be difficult to detect > invalid combinations in bsd.gcc.mk and emit errors? I thought about this a bit more, and am afraid this is not going to scale very well since we might need to have different builds of the same port present then (combinatorial explosion) _or_ keep the varoius lang/gcc ports at maximum fatness. The approach I think we should follow, after thinking quite a bit about it and the experience of the last years, and last but not least looking at how GNU/Linux distributions handle this, is aiming for one canonical port (GCC 4.4 right now) which covers the vast majority of cases, and then have individual exceptions for older software -- but try to keep these low. Gerald
State Changed From-To: open->analyzed Running tinderbox builds with various configurations of gcc.
glarkin 2009-12-18 21:00:03 UTC FreeBSD ports repository Modified files: print/pdftk Makefile Log: - Mark BROKEN until gcj support is working on i386 and amd64 PR: ports/140783 Reported by: pointyhat Revision Changes Path 1.26 +2 -0 ports/print/pdftk/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
glarkin 2009-12-30 23:57:53 UTC FreeBSD ports repository Modified files: print/pdftk Makefile Log: - Force commit to add missing PR: field - Unbreak and enable amd64 build, now that gcc42 port builds gcj42 on i386 and amd64 PR: ports/140783 Revision Changes Path 1.28 +0 -0 ports/print/pdftk/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: analyzed->closed lang/gcc42 has Java (gcj42) support enabled on both i386 and amd64 now. print/pdftk has been updated to build on both platforms as well. Thank you for your report!