public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: "ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp>, binutils@sourceware.org
Subject: Re: Require GNU make?
Date: Thu, 29 May 2014 22:17:00 -0000	[thread overview]
Message-ID: <5387B1FB.4030209@redhat.com> (raw)
In-Reply-To: <53875BB6.6040508@yk.rim.or.jp>

On 05/29/2014 05:09 PM, ISHIKAWA,chiaki wrote:
> (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)

Yeah, GNU make itself assuming GNU make to built itself while
other GNU tools not assuming would be ... a
"wth-are-we-doing-who-are-we-caring-for?" day.

> 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.

Not really.  It just means that before building binutils, you need
to build GNU make.  That is, in effect, push the build system
portability problem to a single and logical entry point, rather
than have all GNU programs (that use make) need to care.  GNU
only needs to invent the wheel once.

> 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.

GNU make even builds with Microsoft's compilers.  At least,
there's README.W32.template in the sources saying that's supported,
and I see "make_msvc_net2003.sln" and "make_msvc_net2003.vcproj" files.

> 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.

Nowadays you're more likely to start by cross compiling, but in any case,
that is really a false problem.  That someone would just have to
port/build GNU make first with the proprietary compiler, _then_
port binutils, then gcc, etc.

-- 
Pedro Alves

  reply	other threads:[~2014-05-29 22:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-19 22:48 [RFA:] fix PR ld/16963, missing SEARCH_DIR for non-sysroot cross-builds Hans-Peter Nilsson
2014-05-20  9:21 ` Alan Modra
2014-05-20 11:23   ` Hans-Peter Nilsson
2014-05-20 12:36     ` Alan Modra
2014-05-20 16:20       ` Hans-Peter Nilsson
2014-05-22  8:02         ` Alan Modra
2014-05-28 13:16         ` Hans-Peter Nilsson
2014-05-28 14:15           ` Alan Modra
2014-05-29 10:08             ` Require GNU make? (was: Re: [RFA:] fix PR ld/16963, missing SEARCH_DIR for non-sysroot cross-builds) Pedro Alves
2014-05-29 12:54               ` Require GNU make? Richard Earnshaw
2014-05-29 13:09                 ` Ralf Corsepius
2014-05-29 13:23                   ` Richard Earnshaw
2014-05-29 16:09                     ` ISHIKAWA,chiaki
2014-05-29 22:17                       ` Pedro Alves [this message]
2014-05-29 22:23                         ` Joel Brobecker
2014-05-29 15:32                   ` Jeff Law
2014-06-04 18:33               ` Tom Tromey
2014-06-02  6:30             ` [RFA:] fix PR ld/16963, missing SEARCH_DIR for non-sysroot cross-builds Alan Modra
2014-06-02 17:28               ` Hans-Peter Nilsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5387B1FB.4030209@redhat.com \
    --to=palves@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=ishikawa@yk.rim.or.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).