All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
To: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: Linux-Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: [PATCH] [RFC] user-cr: Eliminate SUBARCH from Makefile
Date: Fri, 26 Feb 2010 14:54:29 -0600	[thread overview]
Message-ID: <1267217669.15300.118.camel@localhost.localdomain> (raw)
In-Reply-To: <0c6c11c99f939c74b86893d5eac268ce5c612fe7.1267216666.git.matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

On Fri, 2010-02-26 at 12:37 -0800, Matt Helsley wrote:
> [ Depends on recent series of non-RFC Makefile patches ]
> 
> SUBARCH is gross. We shouldn't need to detect the arch to compile to
> using uname. It's bad practice because we could be using a cross compiler,
> or someone may (gag) autoconfiscate this tree. If we must select a true
> subarch, we should just let builders set -mXX in CFLAGS.
> 
> This patch tries to build all of the clone_*.[cSs] files. Any builds
> that fail are quietly ignored and don't get used. One that succeeds
> gets hardlinked to clone.a and subsequently linked into libeclone.a

Hmm, I think detecting the architecture via uname is fine as long as the
user is able to override it (make SUBARCH=foo).

I don't think trying to compile all of clone_* is going to be a good
practice.  For one thing, gcc -m64 on powerpc happily accepted the
32-bit clone wrapper the last time I tried it, hence the #error
directives in clone_ppc*.S.

  parent reply	other threads:[~2010-02-26 20:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-26 20:37 [PATCH] [RFC] user-cr: Eliminate SUBARCH from Makefile Matt Helsley
     [not found] ` <0c6c11c99f939c74b86893d5eac268ce5c612fe7.1267216666.git.matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-02-26 20:54   ` Nathan Lynch [this message]
     [not found]     ` <1267217669.15300.118.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-03-01 15:50       ` [PATCH user-cr] User can override SUBARCH for cross-compilation Oren Laadan
     [not found]         ` <1267458606-1622-1-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-03-01 17:44           ` Nathan Lynch
     [not found]             ` <1267465468.4347.6.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-03-01 19:05               ` Oren Laadan
     [not found]                 ` <4B8C1009.7090905-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-03-01 19:16                   ` Nathan Lynch

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=1267217669.15300.118.camel@localhost.localdomain \
    --to=ntl-e+axbwqsrlaavxtiumwx3w@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.