From owner-freebsd-ports@freebsd.org Mon Dec 12 20:59:29 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D62E3C732C5 for ; Mon, 12 Dec 2016 20:59:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-170.reflexion.net [208.70.211.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86F2D7E1 for ; Mon, 12 Dec 2016 20:59:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4360 invoked from network); 12 Dec 2016 20:59:32 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Dec 2016 20:59:32 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Mon, 12 Dec 2016 15:59:21 -0500 (EST) Received: (qmail 7911 invoked from network); 12 Dec 2016 20:59:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Dec 2016 20:59:21 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id DD3C1EC90AC; Mon, 12 Dec 2016 12:59:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?] From: Mark Millard In-Reply-To: Date: Mon, 12 Dec 2016 12:59:20 -0800 Cc: vbox@FreeBSD.org, Dimitry Andric , svn-ports-head@freebsd.org, FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: References: <86C72DB2-B9ED-4512-A88C-BD1D9A23806F@dsl-only.net> <9D54F0CC-F38C-4CCE-BC33-25C1457BD44B@FreeBSD.org> <5C936BA8-6941-431A-B05F-31030816F85C@dsl-only.net> <487153E5-EF53-4960-9364-23992D7E0F76@dsl-only.net> To: Gerald Pfeifer X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 20:59:29 -0000 [Top post asking if you (Gerald) think portmaster is in error and so if a bugzilla report should be made.] Do you expect that portmaster should instead/also(first) be checking (using the gcc6:lang/gcc6 related example from USE_GCC=3Dany): "pkg query %n-%v gcc6" instead of checking "pkg query %n-%v lang/gcc6"? If yes then a bugzilla report from you (a port maintainer with an example of the issue) may be better than my submitting claims of problems based on a less formal, less complete, less validated knowledge of the intended build environment properties for building ports. I can submit one if you think that is better for some reason. And thanks for all the notes about what I ran into and what you expect should be the case --even if it turned out that at least one official port-building tool did not work that way. (Most of my "knowledge" in the area is inference from the observed behavior of existing code instead of from from reading something indicating the intended properties.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Dec-11, at 2:59 PM, Mark Millard wrote: [After "BUILD_DEPENDS+=3D gcc6:lang/gcc6" below shows that portmaster does not do what you indicate the build environment should do. The beginning is not essential material.] On 2016-Dec-11, at 4:40 AM, Gerald Pfeifer = wrote: > On Sun, 11 Dec 2016, Mark Millard wrote: >> I reported already that devel/kBuild/Makefile has in its >> Makefile: >>=20 >> USE_GCC=3D any >>=20 >> and devel/kBuild is what causes the lang/gcc* build. (I >> reported more than that but it is the part relevant here.) >=20 > I had read that, and I di investigate. It was just setup material (context) for what followed. I had no doubt that you had looked into what I'd reported. > USE_GCC=3Dany is the equivalent of USE_GCC=3D4.2+, and lang/gcc6 and > lang/gcc6-devel should both meet this requirement. >=20 > (In general, do not use a gcc*-devel port unless you really want=20 > or need to, though; use the corresponding gcc* port instead.) In genreal I have avoided *-devel's but with with -r428312 having updated the likes of devel/powerpc64-gcc and devel/amd64-gcc and such to be 6.2.0 based I was exploring what combinations of 6.2.0 installations were compatible vs. not. Historically on, e.g., powerpc64, devel/powerpc64-gcc and the matching lang/gcc* by version conflicted so I picked an alternate lang/gcc* if a devel/powerpc64-gcc updated to match what I already had from lang/gcc* . >> Additional information (gained later) is that if I "pkg delete=20 >> gcc6-devel" then instead of devel/kBuild trying to install lang/gcc6=20= >> it tries to install lang/gcc (no number). >=20 > That works as designed. USE_GCC=3Dyes defaults to lang/gcc. = USE_GCC=3Dany=20 > tries to use an existing GCC system compiler and lang/gcc by default = if=20 > none is present. Understood. >> If I clean that out and put back lang/gcc6-devel and try again it=20 >> goes back to trying to install lang/gcc6 . >=20 > That is a little odd. It means gcc6 from lang/gcc6-devel is found > and identified as a suitable version of GCC. Yep: odd. > Then Mk/bsd.gcc.mk adds >=20 > BUILD_DEPENDS+=3D gcc6:lang/gcc6 >=20 > when it resolves USE_GCC=3Dany. >=20 > That should not trigger and pull in lang/gcc6, though, as long > as gcc6 is found. You are wrong relative to portmaster: it uses (from "sh -x" output, including for its relevant recursive uses): # pkg query %n-%v lang/gcc6 as its test and ends up with am empty response that it interprets as needs-installation. By contrast: # pkg query %n-%v lang/gcc6-devel gcc6-devel-6.2.1.s20161201 gives a match and would be classified as installed. The sh -x output that is relevant: + pm_cd /usr/ports/lang/gcc6 + builtin cd /usr/ports/lang/gcc6 + grep -ql ^CONFLICTS Makefile + origin=3Dlang/gcc6 + iport_from_origin lang/gcc6 + local sn dir + [ -n yes ] + pkg query %n-%v lang/gcc6 + return 1 + iport=3D'' + check_exclude lang/gcc6 + [ -n '' ] + return 0 + [ -n '' -a -n '' ] + [ -n '' -a -n '' ] + [ -n '' ] + check_interactive lang/gcc6 + [ -n '' ] + return 0 + update_port lang/gcc6 + local deps + [ -n '' ] + [ -z '' ] + echo '=3D=3D=3D>>> Launching child to install lang/gcc6' =3D=3D=3D>>> Launching child to install lang/gcc6 + dep_of_deps=3D2 + [ -n pm_first_pass ] + [ ! '(' -n '' -a -n '' ')' ] + num_of_deps=3D2 + deps=3D'(2/2)' + term_printf ' >> devel/kBuild >> lang/gcc6 (2/2)' + echo -e '\n=3D=3D=3D>>> emulators/virtualbox-ose-additions >> = devel/kBuild >> lang/gcc6 (2/2)' =3D=3D=3D>>> emulators/virtualbox-ose-additions >> devel/kBuild >> = lang/gcc6 (2/2) + [ -n '' ] + printf '\033]0;portmaster: emulators/virtualbox-ose-additions >> = devel/kBuild >> lang/gcc6 (2/2)\007' ESC]0;portmaster: emulators/virtualbox-ose-additions >> devel/kBuild >> = lang/gcc6 (2/2)^G+ [ -n doing_dep_check -o '(' -n '' -a -n pm_first_pass = ')' ] + unset NO_DEP_UPDATES + [ -z '' -o -n pm_first_pass ] + sh -x /usr/local/sbin/portmaster -D -K lang/gcc6 + trap trap_exit INT >> It appears to be picking up that a gcc is installed when >> lang/gcc6-devel and that it is is version 6 based but then >> it looks for lang/gcc6 specifically but does not find it >> and so tries to install lang/gcc6. Its identification of the >> version is not enough to identify what specific gcc port >> to look for but it only looks for the one possible source >> to satisfy the dependency --and not finding that specific >> port it then tries to install that specific port that it >> did not find. >=20 > That's pretty close. It finds the gcc6 binary and hence settles > on GCC 6 as the compiler to use, but when resolving dependencies > then it apparently does not find the gcc6 binary (or does, and > something triggers a full rebuild regardless with lang/gcc6 instead=20 > of the original lang/gcc6-devel). See above for what portmaster really does. > Do you, by any chance, have some non-standard settings that would > trigger such an unconditional rebuild? I try to be as standard as I can given that I experiment with clang targeting powerpc64 and powerpc and other such oddities and that I want rather current C++ language/library standards. > In general, for ports work lang/gcc is the one to use, and lang/gccX=20= > over lang/gccX-devel. Relative to lang/gcc vs. lang/gcc* . . . A) devel/powerpc64-gcc and devel/amd64-gcc and the like updated to 6.2.0 at -r428312 . and: B) I want the more current C++ status. Historically I have avoided lang/gcc*-devel . But when devel/*-gcc's update versions I tend to experiment with what combinations conflict for installation vs. what combinations to not. > Somehow it feels your setup adds layers of shaky, untested and > non-standard elements on top of each other. Nope. As stands across /usr/src/ and /usr/ports/ I have around 19 patched files. I do tend to have KERNCONF files that include the standard ones and then change a few things. For ports I try to get by with /etc/make.file having: WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D MALLOC_PRODUCTION=3D But the binutils vintage problems for powerpc64 (system and head ports) and such lead me to do more for the contexts in which I deal with those. I tend to have powerpc64 and powerpc patches because of my experimenting with clang targeting them and that the standard powerpc64 build does not boot PowerMac G5's reliably. Some patches are ones that someone has requested that I try, usually relative to something that I've reported. I also have ones that work around problems so I can see if there is more to report.=20 > As far as lang/gcc* ports are concerned, I believe the best use > of our time will be moving lang/gcc from GCC 4.9 (where it finally > got to) to GCC 5. The only place that I've been using lang/gcc49 was on powerpc64 for my self-hosted libc++ based powerpc64 system builds: For buildworld buildkernel I used: 0) lang/gcc49 analogously to the clang system compiler 1) devel/powerpc64-sxtoolchain-gcc anlogously to a cross compiler toolchain. This was via SRC_CONF_ENV file content to control what was used. > Gerald =3D=3D=3D Mark Millard markmi at dsl-only.net