Date: Sun, 11 Dec 2016 14:59:36 -0800 From: Mark Millard <markmi@dsl-only.net> To: Gerald Pfeifer <gerald@pfeifer.com> Cc: vbox@FreeBSD.org, Dimitry Andric <dim@FreeBSD.org>, svn-ports-head@freebsd.org, freebsd-ports@freebsd.org Subject: Re: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?] Message-ID: <FAE8E195-5F19-4532-A598-58C981EC3A46@dsl-only.net> In-Reply-To: <alpine.LSU.2.20.1612111217090.2333@anthias.pfeifer.com> References: <86C72DB2-B9ED-4512-A88C-BD1D9A23806F@dsl-only.net> <9D54F0CC-F38C-4CCE-BC33-25C1457BD44B@FreeBSD.org> <5C936BA8-6941-431A-B05F-31030816F85C@dsl-only.net> <alpine.LSU.2.20.1611260832560.2407@anthias.pfeifer.com> <487153E5-EF53-4960-9364-23992D7E0F76@dsl-only.net> <F621BEFE-FD1E-4164-86D0-4D0DA2EC02C3@dsl-only.net> <alpine.LSU.2.20.1612111035520.2333@anthias.pfeifer.com> <C22DA1C6-830E-4AB8-BA85-F86235DD9528@dsl-only.net> <alpine.LSU.2.20.1612111217090.2333@anthias.pfeifer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 <gerald at pfeifer.com> =
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.
=20
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FAE8E195-5F19-4532-A598-58C981EC3A46>