svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]

Mark Millard markmi at
Sun Dec 11 10:55:10 UTC 2016

On 2016-Dec-11, at 1:39 AM, Gerald Pfeifer <gerald at> wrote:

> Hi Mark,
> On Sat, 10 Dec 2016, Mark Millard wrote:
>> [Top post of example lack of lang/gcc6-devel vs. lan/gcc6
>> substitutability. Context /usr/ports/ at -r428325 (other
>> than a few specially controlled items.]
> I had another look, and lang/gcc6 and lang/gcc6-devel really are
> substitutable in what they provide.
>> After installing lang/gcc6-devel something else indirectly
>> forced lang/gcc6 to try to build. The attempt failed with:
> That means that "something else indirectly forc[ing] lang/gcc6" is
> what appears to be going on here.  I double checked Mk/
> and failed to find anything (which also would be surprising given
> no other reports in the last decade).
> vbox@, any ideas?
> Gerald

Hi Gerald,

I reported already that devel/kBuild/Makefile has in its

USE_GCC=  any

and devel/kBuild is what causes the lang/gcc* build. (I
reported more than that but it is the part relevant here.)

Additional information (gained later) is that if I "pkg
delete gcc6-devel" then instead of devel/kBuild trying
to install lang/gcc6 it tries to install lang/gcc (no
number). If I clean that out and put back lang/gcc6-devel
and try again it goes back to trying to install lang/gcc6 .

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.

By contrast when no lang/gcc* is present (none installed)
because I've also deleted lang/gcc6-devel it goes for the
default gcc rather than a more specific version: lang/gcc .

This varying behavior might give a clue about what to look
for in the USE_GCC=any mechanism.

Side notes:

On powerpc64 I was able to install both devel/powerpc64-gcc
(with work around for the fact that it is not a true
cross compiler in this context so 6 files do not stage
right) and lang/gcc6 and no conflict was reported.

The mentioned workaround for my context is:

# more ~/ 
cp -ax /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/gcov /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/powerpc64-unknown-freebsd12.0-gcov

cp -ax /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/gcov-tool /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/powerpc64-unknown-freebsd12.0-gcov-tool

gzip -c /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-*/gcc/doc/cpp.1 > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/powerpc64-unknown-freebsd12.0-cpp.1.gz

gzip -c /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/doc/g++.1 > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/powerpc64-unknown-freebsd12.0-g++.1.gz

gzip -c /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/doc/gcc.1 > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/powerpc64-unknown-freebsd12.0-gcc.1.gz

gzip -c /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-*/gcc/doc/gcov.1 > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/powerpc64-unknown-freebsd12.0-gcov.1.gz

after which I use -C with portmaster to let it continue now
that it can find the 6 files when it tries to.

There are other issues in how things are operating and
I'll not look into them until after I've gotten some sleep
(or even later then that).

Mark Millard
markmi at

> The specific example turns out to be. . .
> emulators/virtualbox-ose-additions leads to:
> ===>>> The following actions will be taken if you choose to proceed:
>        Upgrade virtualbox-ose-additions-5.1.8 to virtualbox-ose-additions-5.1.10
>        Install devel/kBuild
>        Install lang/gcc6
>        Install textproc/flex
> and lang/gcc6 tries to build during devel/kBuild and the 3
> non-lang/gcc6 items above have:
> # grep -i gcc emulators/virtualbox-ose-additions/Makefile devel/kBuild/Makefile textproc/flex/Makefile 
> emulators/virtualbox-ose-additions/Makefile:CONFIGURE_ARGS+=    --nofatal --with-gcc="${CC}" --with-g++="${CXX}"
> emulators/virtualbox-ose-additions/Makefile:    @${ECHO} 'VBOX_GCC_std = -std=c++11' >> ${WRKSRC}/LocalConfig.kmk
> emulators/virtualbox-ose-additions/Makefile:    @${ECHO} 'VBOX_GCC_Wno-unused-parameter = -Wno-unused-parameter' >> \
> devel/kBuild/Makefile:USE_GCC=  any
> devel/kBuild/Makefile:          ${REINPLACE_CMD} -e 's|gcc|${CC}|g' $$f ; \
> In a context with:
> # pkg info | grep -i gcc
> gcc6-devel-6.2.1.s20161201     GNU Compiler Collection 6
> powerpc64-gcc-6.2.0            Cross GNU Compiler Collection for powerpc64
> powerpc64-xtoolchain-gcc-0.1   Pre seeded toolchain to cross build FreeBSD base
> # more /etc/make.conf 
> #
> DEFAULT_VERSIONS+=perl5=5.24
> WRKDIRPREFIX=/usr/obj/portswork
> So apparently lang/gcc6-devel can not substitute for lang/gcc6
> automatically.
> Now that devel/powerpc64-gcc is 6.2.0 based it and lang/gcc6 may also
> conflict (I do not know yet: build in progress).
> ===
> Mark Millard
> markmi at

More information about the freebsd-ports mailing list