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

[Mark Millard]

[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.]

After installing lang/gcc6-devel something else indirectly
forced lang/gcc6 to try to build. The attempt failed with:

Installing gcc6-6.2.0...
pkg-static: gcc6-6.2.0 conflicts with gcc6-devel-6.2.1.s20161201 (installs files into the same place).  Problematic file: /usr/local/bin/x86_64-portbld-freebsd12.0-c++6
*** Error code 70

Stop.
make[1]: stopped in /usr/ports/lang/gcc6
*** Error code 1


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 
WANT_QT_VERBOSE_CONFIGURE=1
#
DEFAULT_VERSIONS+=perl5=5.24
WRKDIRPREFIX=/usr/obj/portswork
WITH_DEBUG=
WITH_DEBUG_FILES=
MALLOC_PRODUCTION=


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 dsl-only.net

Older material:

On 2016-Nov-26, at 4:16 PM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2016-Nov-25, at 11:47 PM, Gerald Pfeifer <gerald at pfeifer.com> wrote:
> 
>> On Fri, 25 Nov 2016, Mark Millard wrote:
>>> I wonder if that leaves lang/gcc and lang/gcc49 as conflicting.
>> 
>> Yes, these two ports conflict for the time being, and are properly
>> marked as such.
>> 
>> (And I am looking for a more elegant approach going forward, in 
>> particular when we move into GCC 5 territory where, based on input 
>> from Tijl and others, we now distinguish between lang/gcc5 and 
>> lang/gcc5-devel.)
> 
> That explains why I've only had lang/gcc5 vs. devel/powerpc64-gcc
> conflicts at times: devel/powerpc64-gcc is not treated as a 3rd
> alternative to lang/gcc5-devel and lang/gcc5 and it overlaps with
> lang/gcc5 when the .x part of the versions (of .x.y) happen to be
> the same.
> 
> [Long ago it was devel/powerpc64-gcc and lang/gcc49 conflicts.]
> 
> devel/powerpc64-gcc is currently a gcc5 variant. I actually
> install and use devel/powerpc64-xtoolchain-gcc and its
> devel/powerpc64-gcc on the powerpc64 contexts that I have. (This
> requires a staging-failure workaround.) I learned to avoid
> having lang/gcc5 (in more modern times). Sounds like I could
> have lang/gcc5-devel without conflicts.
> 
> I use devel/powerpc64-gcc for "self hosted cross builds" in order
> to have a modern libc++ based powerpc64 environment without
> requiring actual cross builds. [I've never gotten lib32 to
> work under this technique so I build without it.]
> 
>>> But luckily so far I've not picked to build anything that built
>>> lang/gcc. Or, more likely(?), if some gcc is already installed it
>>> is used instead if lang/gcc is not installed yet.
>> 
>> Correct.  If lang/gcc49 or lang/gcc is installed, either of the
>> two is picked up; if a newer version is installed and USE_GCC=yes
>> or USE_GCC=X.Y+ are requested (and the installed version is newer),
>> that one is used.
>> 
>> Nothing to do with luck on your side, Mark.  Rather, design and 
>> implementation in the Ports Collection. :-)
>> 
>> Gerald
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net