From: ramsdell@mitre.org (John D. Ramsdell)
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: CFLAGS are for C compilers and other Unix traditions
Date: 21 May 2006 12:40:03 -0400 [thread overview]
Message-ID: <ogtac9bcows.fsf@quake.mitre.org> (raw)
In-Reply-To: <c3eb784636090763af47f3aec7327c4e@cl.cam.ac.uk>
Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> On 21 May 2006, at 03:58, John D. Ramsdell wrote:
>
> > If you execute this command, you will note that the rule for
> > assembling .S files is:
> >
> > COMPILE.S = $(CC) $(ASFLAGS) $(CPPFLAGS) $(TARGET_MACH) -c
> >
> > Note that you don't give the assembler CFLAGS. It's not a C
> > compiler.
>
> We fixed this for Xen itself some time ago. If there are other places
> in the tree that do this (maybe minios?), please do provide a patch.
The Mini-OS makefile was recently patched so as to include the
following rules:
%.o: %.c $(HDRS) Makefile
$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@
%.o: %.S $(HDRS) Makefile
$(CC) $(ASFLAGS) $(CPPFLAGS) -c $< -o $@
Note the rules fail to include $(TARGET_MACH), which is part of the
default rule for COMPILE.S, and $(TARGET_ARCH), which is normally
part of COMPILE.c.
When the appropriate GCC backends are installed on an i386 32-bit
machine, the $(TARGET_MACH) flags, and the $(TARGET_ARCH) flags can be
used to produce a Mini-OS elf file for both the 32 and 64 i386
architectures. You don't have to put your cross compilers in separate
locations.
I decided to test the use of Mini-OS as a library. My test
application included just one file, app.c, and it resided in a
directory outside the Xen sources. I wrote the obvious Makefile, and
used the default rule to build app.o from app.c.
This Makefile fails, of course, because $(TARGET_ARCH) is set to
x86_32 by Config.mk, and the default rule is:
COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
I hadn't tracked down the source of my problem before I sent my post
last night. I somehow thought that COMPILE.c used $(TARGET_MACH),
instead of $(TARGET_ARCH), and therefore thought a fix was plausible.
I now see that modifying Xen to work with the default rules is a big
pain. On the plus side, tracking down this problem forced me to
look at Config.mk, and see I can select a cross-compiler by setting
CROSS_COMPILER to the bin directory of my cross compiler, rather than
setting my path.
John
next prev parent reply other threads:[~2006-05-21 16:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1FhcWV-0004n6-Dm@host-192-168-0-1-bcn-london>
2006-05-21 2:58 ` CFLAGS are for C compilers and other Unix traditions John D. Ramsdell
2006-05-21 8:48 ` Keir Fraser
2006-05-21 16:40 ` John D. Ramsdell [this message]
2006-05-21 17:12 ` John D. Ramsdell
2006-05-22 10:31 ` [PATCH] Mini-OS Makefile TARGET_ARCH becomes MINIOS_TARGET_ARCH John D. Ramsdell
2006-05-22 13:20 ` Keir Fraser
2006-05-22 16:47 ` John D. Ramsdell
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=ogtac9bcows.fsf@quake.mitre.org \
--to=ramsdell@mitre.org \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/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.