Trying to build /usr/ports/print/ghostscript8 with the following command results in a compilation failure: env TARGET_ARCH=i386 make as seen in this excerpted output: ===== start excerpt ===== cc -O2 -pipe -fno-strict-aliasing -DUPD_SIGNAL=0 -I. -I/usr/workdir/usr/ports/print/ghostscript8/work/ghostscript-8.71/jasper/src/libjasper/include -I/usr/local/include/libpng -I/usr/local/include i386 -c -o ert.o ert.c cc: i386: No such file or directory ert.c: In function 'printUsageAndExit': ert.c:34: warning: incompatible implicit declaration of built-in function 'exit' ert.c: In function 'main': ert.c:52: warning: incompatible implicit declaration of built-in function 'malloc' ert.c:55: warning: incompatible implicit declaration of built-in function 'exit' ert.c:63: warning: incompatible implicit declaration of built-in function 'strlen' ert.c:73: warning: incompatible implicit declaration of built-in function 'exit' ert.c:82: warning: incompatible implicit declaration of built-in function 'exit' ert.c:87: warning: incompatible implicit declaration of built-in function 'exit' ert.c:116: warning: incompatible implicit declaration of built-in function 'exit' gmake: *** [ert.o] Error 1 *** Error code 2 Stop in /usr/ports/print/ghostscript8. ===== end excerpt ===== Note the incorrect inclusion of "i386" just before the -c option in the "cc" command line. This is the same problem found in the following problem reports: http://www.freebsd.org/cgi/query-pr.cgi?pr=147853 http://www.freebsd.org/cgi/query-pr.cgi?pr=151224 It seems to me that someone knowledgeable about this problem should take on the task of searching the entire ports collection for all instances of this same bug, rather than hoping random end users will eventually discover and report them all one at a time. I wasted a lot of time trying to solve this problem before I eventually ran across those other PRs - this should not be repeated. Fix: The attached patch worked for me, although I admit to not really understanding the problem. Note that this is essentially the same fix as for PR ports/147853 (see mail/ssmtp/Makefile, revision 1.32), but I am wondering whether there is some reason why the fix for PR ports/151224 as implemented in multimedia/x264/Makefile, revision 1.79 includes the clearing of not only TARGET_ARCH, but also ARCH. Patch attached with submission follows: How-To-Repeat: env TARGET_ARCH=i386 make
Responsible Changed From-To: freebsd-ports-bugs->doceng Over to maintainer (via the GNATS Auto Assign Tool)
Please provide an explanation as to why this bug report has been utterly ignored for a month. Is 'doceng' really the correct responsible party for this bug? I have no idea myself, but since he/she/it appears to be nonfunctional, perhaps a more responsible party can handle this report.
hrs 2011-05-23 20:43:10 UTC FreeBSD ports repository Modified files: print/ghostscript8 Makefile print/ghostscript8/files Makefile.epag Added files: print/ghostscript8/files patch-lib-pdf2dsc.ps Log: - Fix a problem when opening a PDF file. - Fix a build issue when TARGET_ARCH is defined. PR: ports/156654 PR: ports/156607 Revision Changes Path 1.205 +1 -1 ports/print/ghostscript8/Makefile 1.3 +2 -2 ports/print/ghostscript8/files/Makefile.epag 1.1 +11 -0 ports/print/ghostscript8/files/patch-lib-pdf2dsc.ps (new) _______________________________________________ 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: open->closed Sorry for the long delay. A patch for the problem has been committed. Please try the latest version and let us know if it persists on your environment. Thank you for your report.
hrs, thanks for implementing a fix. The ghostscript8 port now successfully cross-builds for a i386 target in my amd64 environment. I would like to make a suggestion though. The solution you used differs from my patch, which I derived naively from ports/147853 and ports/151224 because I don't really understand the problem. If you could give a brief explanation of your solution here, it might help other developers faced with this problem. I ask this in part because I've since filed PR ports/157457 because of the same bug in lang/lua and will shortly be filing at least two more essentially identical PRs against other ports. This bug seems to be far too common in the FreeBSD ports collection. As a more general comment, I would again like to plead that someone take on the task of systematically finding and fixing all ports with this problem rather than depending on end users to find and report these one at a time. Carl / K0802647
----Security_Multipart(Thu_Jun__2_15_32_14_2011_023)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carl <k0802647@telus.net> wrote in <201105312150.p4VLo6bo095718@freefall.freebsd.org>: k0> ports/151224 because I don't really understand the problem. If you could k0> give a brief explanation of your solution here, it might help other k0> developers faced with this problem. I ask this in part because I've This problem is due to TARGET_ARCH is used in gmake's default compile rule for .c files. It is actually defined as "$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH)" in the binary. So, if gmake is invoked with TARGET_ARCH defined, the value is inserted into just after the value of CPPFLAGS. One of Makefiles in print/ghostscript8 failed because there was no explicit rule for compilation. Adding a rule also solves this, but I decided to use BSD make instead since the Makefile did not contain GNU make specific syntax. It is likely that this can be applied to almost all of ports which rely on GNU make. k0> other ports. This bug seems to be far too common in the FreeBSD ports k0> collection. Well, I am not sure if this is bug or not. Did defining TARGET_ARCH really help your cross-compilation? I guess that variable is supported in /usr/src only, and noop for the ports tree. -- Hiroki ----Security_Multipart(Thu_Jun__2_15_32_14_2011_023)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3nLm4ACgkQTyzT2CeTzy1ONwCfQd6WHqFLBS550/wahppDBto2 tcAAnRct1uThT4imCMiaGuTDxkM2eDny =t2PM -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Jun__2_15_32_14_2011_023)----
On 2011-06-01 11:32 PM, Hiroki Sato wrote: > k0> other ports. This bug seems to be far too common in the FreeBSD ports > k0> collection. > > Well, I am not sure if this is bug or not. Did defining TARGET_ARCH > really help your cross-compilation? I guess that variable is > supported in /usr/src only, and noop for the ports tree. I have been cross-compiling ports on an amd64 system for use on an i386 system. Whether I use make directly or indirectly via portmaster, I specify both TARGET=i386 and TARGET_ARCH=i386 to accomplish this, as per the build(7) man page and as I see done by the FreeNAS developers. It is true that the man page says "If not set, TARGET_ARCH defaults to the current machine architecture, unless TARGET is also set, in which case it defaults to the appropriate value for that platform. Typically, one only needs to set TARGET." Does that not mean that TARGET_ARCH ends up getting set anyway? I admit I do not know why both variables exist. Carl
----Security_Multipart(Fri_Jun__3_09_29_23_2011_355)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carl <k0802647@telus.net> wrote in <201106020740.p527eAk5019427@freefall.freebsd.org>: k0> I have been cross-compiling ports on an amd64 system for use on an i386 k0> system. Whether I use make directly or indirectly via portmaster, I k0> specify both TARGET=i386 and TARGET_ARCH=i386 to accomplish this, as per k0> the build(7) man page and as I see done by the FreeNAS developers. It is Well, TARGET and TARGET_ARCH have no effect for /usr/ports. They are for /usr/src only at this moment (see build(7) and ports(7) carefully). Can you try the following on an i386 box: % cd /usr/ports/devel/gmake % make TARGET_ARCH=amd64 clean all % file work/make-3.82/make and then, on an amd64 box try to build without TARGET_ARCH like this: % cd /usr/ports/devel/gmake % make clean all % file work/make-3.82/make If the cross-compilation finished as you intended, both show the same results; more specifically, file(1) commands should show the following: % file work/make-3.82/make work/make-3.82/make: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped % What is the result on your environment? If an i386 binary was built on the i386 box even if TARGET_ARCH=amd64 was defined, the output should have become the following: % file work/make-3.82/make work/make-3.81/make: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped % This output means cross-compilation was not done actually, and the i386 box just built packages for i386. -- Hiroki ----Security_Multipart(Fri_Jun__3_09_29_23_2011_355)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3oKuMACgkQTyzT2CeTzy3zDACeKtalxRnn+aK2z6YXyAMYi3fV frsAoLJkXuGk+F6cnzhRA26ZhB++kUYM =41PA -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun__3_09_29_23_2011_355)----
On 2011-06-02 5:29 PM, Hiroki Sato wrote: > Well, TARGET and TARGET_ARCH have no effect for /usr/ports. They are > for /usr/src only at this moment (see build(7) and ports(7) carefully). The build(7) wording is quite clear that it is meant to apply to /usr/src, /usr/doc, and /usr/ports, with yet additional information in ports(7) for /usr/ports. However, I performed the tests you suggested and you are quite right that TARGET_ARCH is having no effect on a build of gmake. I got this when doing a build without TARGET_ARCH specified on a v8.2 amd64 system: "ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped" and this when specifying TARGET_ARCH=amd64 on a v8.1 i386 system: "ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.1, not stripped" A quick grep of /usr/ports indicates that very few ports actually reference TARGET_ARCH, but there are some. Although it is clear that I could therefore stop setting TARGET_ARCH for port cross-builds, I think the POLA needs to be considered here, Hiroki. IMHO, it is indeed astonishing for any build to fail merely because there is an unnecessary variable set in the environment - it should be harmless. And in the case of TARGET_ARCH, this would not be an unusual situation when one is cross-building world+ports using the same build environment. I still want to suggest that some global solution for all gmake-dependent ports in the collection should be found to render TARGET_ARCH harmless. Carl
Hm, found this after writing a similar explanation for PR ports/157479. > The build(7) wording is quite clear that it is meant to apply to > /usr/src, /usr/doc, and /usr/ports, with yet additional information in > ports(7) for /usr/ports. No, build(7) writes about how to build the system from /usr/src and and points you to the ports(7) manpage for portbuilding. Maybe with an extra blank line this will be more clear. NAME build -- information on how to build the system DESCRIPTION The sources for the FreeBSD system and its applications are contained in three different directories, normally /usr/src, /usr/doc, and /usr/ports. Directory /usr/src contains the ``base system'' sources, which is loosely defined as the things required to rebuild the system to a useful state. Directory /usr/ports contains a tree that provides a consistent interface for building and installing third party applications. For more information about the ports build process, see ports(7). ==> in ports(7) you will not find a reference for TARGET_ARCH // olli
----Security_Multipart(Sat_Jun__4_09_13_30_2011_535)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit olli hauer <ohauer@gmx.de> wrote in <201106032110.p53LAEOX026932@freefall.freebsd.org>: oh> Hm, found this after writing a similar explanation oh> for PR ports/157479. oh> oh> > The build(7) wording is quite clear that it is meant to apply to oh> > /usr/src, /usr/doc, and /usr/ports, with yet additional information in oh> > ports(7) for /usr/ports. oh> oh> No, build(7) writes about how to build the system from /usr/src and oh> and points you to the ports(7) manpage for portbuilding. oh> oh> Maybe with an extra blank line this will be more clear. True. For TARGET and TARGET_ARCH, the following sentences in the ENVIRONMENT section clearly say these environment variables are effective in /usr/src only: | | Additionally, builds in /usr/src are influenced by the following make(1) | variables: | | ... | | TARGET The target hardware platform. ... | | ... | | TARGET_ARCH The target machine processor architecture. ... | I agree that TARGET_ARCH in /usr/src and in GNU Make are confused. However, trying to cross-build the ports tree is completely unsupported (at this moment) and there is a fact that TARGET_ARCH has been used in GNU Make for another purpose for a long time. So, "don't define that" is a simple answer. Even if TARGET_ARCH defined for src tree build, undefining TARGET_ARCH only for ports tree is quite easy (by make.conf, for example). I am wondering if you have any specific reason not to do so. k0> I still want to suggest that some global solution for all k0> gmake-dependent ports in the collection should be found to render k0> TARGET_ARCH harmless. What do you want more specifically? Unconditionally undefining TARGET_ARCH before building ports in bsd.port.mk would be easy to implement, but is that what you want? -- Hiroki ----Security_Multipart(Sat_Jun__4_09_13_30_2011_535)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3peKoACgkQTyzT2CeTzy0NKQCgj8354X3aUQGxjAQ7qWAE6Log HZYAnA9shaJiMps34hRDfIPQnphW7wU/ =izn7 -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Jun__4_09_13_30_2011_535)----
On 2011-06-03 5:13 PM, Hiroki Sato wrote: > I agree that TARGET_ARCH in /usr/src and in GNU Make are confused. > However, trying to cross-build the ports tree is completely > unsupported (at this moment) and there is a fact that TARGET_ARCH has > been used in GNU Make for another purpose for a long time. That's good information to know. I had no idea that cross-building is=20 only supported for world. It surely does make it hard to use FreeBSD in=20 embedded systems based on the officially supported processor=20 architectures though. Embedded systems often don't work well as build=20 platforms, so cross-building is sometimes the only way to go. Is there a=20 roadmap that projects when FreeBSD will be production-ready for embedded=20 systems? > So, > "don't define that" is a simple answer. Even if TARGET_ARCH defined > for src tree build, undefining TARGET_ARCH only for ports tree is > quite easy (by make.conf, for example). I am wondering if you have > any specific reason not to do so. I don't have a reason anymore, but the reason before was the same as it=20 will undoubtedly continue to be for others - it's entirely non-obvious=20 and undocumented that having TARGET_ARCH set can break port builds. If I=20 hadn't run across Olivier Cochard-Labb=E9's experience tripping over the=20 same issue (ports/147853 and ports/151224 bug reports), I'd still be=20 trying to figure it out. > k0> I still want to suggest that some global solution for all > k0> gmake-dependent ports in the collection should be found to render > k0> TARGET_ARCH harmless. > > What do you want more specifically? Unconditionally undefining > TARGET_ARCH before building ports in bsd.port.mk would be easy to > implement, but is that what you want? Lack of knowledge on my part says I probably shouldn't speculate as to a=20 specific global solution, but could the gmake port itself be modified to=20 be more FreeBSD-compatible? All I know is that gmake can do something=20 strange and unexpected in a FreeBSD environment, so if there's a way to=20 neutralize that so port developers needn't worry about end users getting=20 sandbagged by a supposedly unused and irrelevant variable, then users=20 needn't keep rediscovering the problem and/or filing bug reports of this=20 sort. Carl