This is the mail archive of the
mailing list for the binutils project.
Re: Require GNU make?
- From: "ISHIKAWA,chiaki" <ishikawa at yk dot rim dot or dot jp>
- To: binutils at sourceware dot org
- Date: Fri, 30 May 2014 01:09:26 +0900
- Subject: Re: Require GNU make?
- Authentication-results: sourceware.org; auth=none
- References: <201405201619 dot s4KGJpRg002591 at ignucius dot se dot axis dot com> <201405281315 dot s4SDFpU2031819 at ignucius dot se dot axis dot com> <20140528141505 dot GJ6679 at bubble dot grove dot modra dot org> <53870721 dot 3080402 at redhat dot com> <53872DEC dot 1050209 at arm dot com> <538730C1 dot 6040105 at rtems dot org> <538734C8 dot 4030300 at arm dot com>
(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 :-)
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.
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