Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 04 Oct 2015 18:16:18 +0200
From:      =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= <fbl@aoek.com>
To:        Michelle Sullivan <michelle@sorbs.net>
Cc:        freebsd-arm@freebsd.org, freebsd-ports@freebsd.org
Subject:   Re: Uses/compiler.mk does not trigger under RBPi
Message-ID:  <a67b09419a2ec9e1cad68bc631ea31df@mail.yourbox.net>
In-Reply-To: <561105DD.1030903@sorbs.net>
References:  <bfe1c24f878ca90245680b2cfae1f6d2@mail.yourbox.net> <560DCFD7.30509@sorbs.net> <c5f4ab0adc751410b8205e6f3aedda57@mail.yourbox.net> <560FAAA4.6080800@sorbs.net> <561105DD.1030903@sorbs.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Michelle,
this makes sense, there are two bugs.

1) there is a bug somewhere in Mk/* that pulls USES/compiler.mk in also 
when USES+=compiler is not specified, AND the processor is Intel/AMD (or 
at least not ARM)
2) the following ports Makefile are broken in the sense that they use 
COMPILER_TYPE but do not call for USES+=compiler properly
CANDIDATES=$(find /usr/ports -name Makefile -exec fgrep -l COMPILER_TYPE 
"{}" \;)

for c in ${CANDIDATES}; do
   [ -z "`awk '/USES/ && /compiler/' "${c}"`" ] && echo ${c}
done
/usr/ports/devel/arm-none-eabi-gcc/Makefile
/usr/ports/devel/gcc-arm-embedded/files/Makefile
/usr/ports/devel/powerpc64-xtoolchain-gcc/Makefile
/usr/ports/graphics/hugin/Makefile
/usr/ports/lang/gcc/Makefile
/usr/ports/lang/gcc5-devel/Makefile
/usr/ports/lang/gcc5/Makefile
/usr/ports/lang/gcc6-devel/Makefile

Do you agree?

Any ideas to help identify 1)? Thank you.

Regards,

---
José Pérez

El 2015-10-04 12:56, Michelle Sullivan escribió:
> Michelle Sullivan wrote:
>> José Pérez wrote:
>> 
>>> Hi Michelle,
>>> thank you for your suggestion. Is this another workaround?
>>> 
>> 
>> As far as I was aware if you need Uses/compiler.mk it should be
>> specified (there are params if a particular compiler/feature set is
>> required) with USES+=compiler
>> 
>> 
>>> I mean: many port Makefiles are affected, in the sense that when 
>>> built
>>> on Intel/AMD the ports just work because Uses/compiler.mk is sucked 
>>> in
>>> automatically, but it is not on ARM.
>>> 
>> 
>> But do they need Uses/compiler.mk ?  If so then it might be someone
>> screwed up, if they don't actually need it then that would be why it's
>> not specified.
>> 
>> 
>>> So, shall I report a bug on all the ports that use COMPILER_TYPE, or
>>> is there a way to have ARM trigger Uses/compiler.mk?
>>> 
>> 
>> If they use/require COMPILER_TYPE and don't specify USES+= compiler 
>> then
>> I would log a bug for each port and let the ports manager take care of
>> it as it's probably a change in default behavior that has caused the
>> mess... how many are we talking about?  10+, 100+, 1000+?
>> 
>> 
> 
> Another (additional) thought is that if amd64/i386 is automatically
> pulling in Uses/compiler.mk when it is not explicitly requested, one
> could consider that in itself a (the) bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a67b09419a2ec9e1cad68bc631ea31df>