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.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
