Uses/ does not trigger under RBPi

José Pérez fbl at
Sun Oct 4 16:16:34 UTC 2015

Hi Michelle,
this makes sense, there are two bugs.

1) there is a bug somewhere in Mk/* that pulls USES/ 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}

Do you agree?

Any ideas to help identify 1)? Thank you.


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/ 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/ is sucked 
>>> in
>>> automatically, but it is not on ARM.
>> But do they need Uses/ ?  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/
>> 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/ when it is not explicitly requested, one
> could consider that in itself a (the) bug.

More information about the freebsd-ports mailing list