From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13976 invoked by alias); 29 May 2014 16:09:39 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 13960 invoked by uid 89); 29 May 2014 16:09:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: phnompenh.mbos.jp Received: from mbos141-211.alpenstock.jp (HELO phnompenh.mbos.jp) (220.156.141.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 May 2014 16:09:37 +0000 Received: from [172.16.30.41] ([172.16.30.41]) by phnompenh.mbos.jp ([172.16.30.51]) with ESMTP id 2014053001:09:32:164103.13044.54905744 for ; Fri, 30 May 2014 01:09:32 +0900 (JST) Received: (qmail 693 invoked from network); 30 May 2014 01:09:32 +0900 Received: from nttkyo856238.tkyo.nt.ftth.ppp.infoweb.ne.jp (HELO [192.168.0.65]) (ishikawa_yk@smp.mbos.jp@[116.83.25.238]) (envelope-sender ) by pyongyang.mbos (qmail-ldap-1.03) with SMTP for ; 30 May 2014 01:09:32 +0900 Message-ID: <53875BB6.6040508@yk.rim.or.jp> Date: Thu, 29 May 2014 16:09:00 -0000 From: "ISHIKAWA,chiaki" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: binutils@sourceware.org Subject: Re: Require GNU make? References: <201405201619.s4KGJpRg002591@ignucius.se.axis.com> <201405281315.s4SDFpU2031819@ignucius.se.axis.com> <20140528141505.GJ6679@bubble.grove.modra.org> <53870721.3080402@redhat.com> <53872DEC.1050209@arm.com> <538730C1.6040105@rtems.org> <538734C8.4030300@arm.com> In-Reply-To: <538734C8.4030300@arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TERRACE-SPAMMARK: NOT spam-marked. (by Terrace) X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00271.txt.bz2 (2014/05/29 22:23), Richard Earnshaw wrote: > On 29/05/14 14:06, Ralf Corsepius wrote: >> On 05/29/2014 02:54 PM, Richard Earnshaw wrote: >> >>> Not directly relevant, but I put a feature into the newlib build earlier >>> this year that relied on a GNU make extension. There were no objections >>> at the time I did that. >> Correct me if I'm wrong, but IIRC, GCC already requires gmake. >> As newlib is commonly used with GCC, probably everybody who uses newlib >> also uses gmake :-) >> >> Ralf >> >> > > Possibly. As I said, it's not directly relevant... > > I tend to build all off gcc/binutils/gdb/newlib in one go, so always use > gmake for the lot. > > R. > Hi, I don't know the recent code, but at least long time ago, 'Makefile' for gmake used portable constructs only so that gmake source files can be compiled and linked to produce gmake binary with BSDmake and other variants of make look-alikes. (I think there was even a special makefile for DOS-based DeLorie-GCC environment) There is a bootstrapping issue of native binutils tools for a new CPU, say, when there is only a limited set of available tools under a given OS for which the CPU vendors are providing initial support limited. Selection of GNUmake or BSDmake can be such an issue. But, today, we have Cygwin that runs well (albeit slowly in terms of I/O) under Windows even so that cross-compilation using gmake is possible under Windows platforms, POSIX-platforms such as linux, Mac OSX, FreeBSD, Solaris, and even on a single board computer environemtn Raspberry-PI using Debian-based linux distribution. Creating a cross-compilation chain using GCC and binutils for a new CPU is not an impossible task [or it is not that difficult to write a wrapper that lets a proprietary cross-compiler from the CPU vendor to understand options passed to GCC reasonably well for compilation purposes at least], I think using gmake-specific constructs in Makefile(s) for native and cross binutils is OK as long as it is clearly documented and self-checking code is embedded in Makefile. We don't want incorrect compilation that produce seemingly complete binary due to the mishandling of non-portable make rules, and such. Maybe someone who has ported binutils tools RECENTLY to a new CPU using the proprietary (cross-)compiler (and assembler and linker, more importantly) from a CPU vendor and had some difficulty because of the limitation of tools on the particular OS which the CPU vendor chose for initial support can comment on this. I doubt difference of make versions is not a major cause of headache these days (in principle!) Just a thought from an observer who has used microprocessors since late 1970's...