From owner-freebsd-arm@freebsd.org Sun Oct 4 16:16:34 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19C89A104B2; Sun, 4 Oct 2015 16:16:34 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from srv56-45.cdn.bestreaming.com (ns330343.ip-37-187-119.eu [37.187.119.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6DCF614DD; Sun, 4 Oct 2015 16:16:32 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.7/8.14.7) with ESMTP id t94GGIkL098800; Sun, 4 Oct 2015 18:16:18 +0200 (CEST) (envelope-from fbl@aoek.com) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 04 Oct 2015 18:16:18 +0200 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= To: Michelle Sullivan Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Uses/compiler.mk does not trigger under RBPi In-Reply-To: <561105DD.1030903@sorbs.net> References: <560DCFD7.30509@sorbs.net> <560FAAA4.6080800@sorbs.net> <561105DD.1030903@sorbs.net> Message-ID: X-Sender: fbl@aoek.com User-Agent: Roundcube Webmail/1.0.3 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 16:16:34 -0000 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.