Bug 156607 - print/ghostscript8: setting TARGET_ARCH variable prevents compilation
print/ghostscript8: setting TARGET_ARCH variable prevents compilation
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: Normal Affects Only Me
Assigned To: doceng
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-24 10:20 UTC by k0802647
Modified: 2011-06-04 04:00 UTC (History)
0 users

See Also:


Attachments
file.diff (396 bytes, patch)
2011-04-24 10:20 UTC, k0802647
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description k0802647 2011-04-24 10:20:07 UTC
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
Comment 1 Edwin Groothuis freebsd_committer 2011-04-24 10:20:17 UTC
Responsible Changed
From-To: freebsd-ports-bugs->doceng

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 k0802647 2011-05-22 05:11:06 UTC
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.
Comment 3 dfilter freebsd_committer 2011-05-23 21:43:20 UTC
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"
Comment 4 Hiroki Sato freebsd_committer 2011-05-23 21:43:43 UTC
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.
Comment 5 k0802647 2011-05-31 22:47:50 UTC
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
Comment 6 Hiroki Sato freebsd_committer 2011-06-02 07:32:14 UTC
----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)----
Comment 7 k0802647 2011-06-02 08:37:10 UTC
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
Comment 8 Hiroki Sato freebsd_committer 2011-06-03 01:29:23 UTC
----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)----
Comment 9 k0802647 2011-06-03 10:40:38 UTC
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
Comment 10 ohauer 2011-06-03 22:07:50 UTC
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
Comment 11 Hiroki Sato freebsd_committer 2011-06-04 01:13:30 UTC
----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)----
Comment 12 k0802647 2011-06-04 03:54:55 UTC
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