Hi Ben,
On 2011-06-27 Benjamin Franksen wrote:
>
> I have decided to split the compiler tests into two parts: the first calls
> only snc and has the strict checks for the output (counts "error" and
> "warning" words). This works since I have the snc compiler under my own
> control. Also, since snc output does not depend on the target arch, it
> suffices to do these tests once (i.e for the HOST arch). The second group
> will test the whole tool chain and is used only for those tests that need
> to rely on the C compiler/preprocessor to reject certain constructs
> generated by snc. These tests call `make -s -B TESTPROD=$test` but do not
> inspect the output, they only check the return code. These tests can and
> should be performed for all target archs.
That sounds good.
> > You're going to have "fun" with this test on Macs, which can be
> > configured to actually execute the C compiler up to 4 times when you run
> > gcc once, depending on the setting for ARCH_CLASS which sends a -arch
> > option to gcc. This is how you get it to generate Fat Binaries, which
> > contain code for more than one processor architecture. The EPICS build
> > system configuration lets individual sites decide what architectures
> > they want to include in their binaries on darwin.
> >
> > If you look at the comments in the file
> > base/configure/os/CONFIG_SITE.Common.darwin-ppcx86
> > you'll get some idea of the possible combinations (the CONFIG_SITE files
> > for the other darwin target-architectures contain a reduced list of
> > possibilities, but in practice any target-arch can be configured to
> > build for any combination of binaries).
>
> I don't understand why things have been done this way. I thought 'target
> architecture' means what it says?
>
> > This means you shouldn't try to
> > rely on EPICS_HOST_ARCH containing the string "64" when you're building
> > for a 64-bit CPU, and even if it does it isn't necessarily going to be
> > /only/ building for a 64-bit CPU.
>
> Hm, does that also mean I can not even rely on parsing the current
> directory to find out which target arch I am on? Could I test the value of
> ARCH_CLASS in the Makefile to decide whether a test should fail or not?
The fat binary behavior I'm talking about is something that Apple does on the
Mac and which Mac users with mixed architectures are used to; EPICS still only
thinks its building for one target architecture so our rules don't change and
you can rely on everything you normally do as far as the build process goes,
but whenever make executes "$(CC) -c $(CFLAGS) file.c" the C compiler gets
executed internally once for each CPU architecture given in its -arch options,
and the resulting object code for all CPUs gets combined into a single .o
file. Similar things happen during linking.
Apple do hide the process of building fat binaries pretty well, but parsing
the linker or compiler output is likely to get confusing since each internal
compilation can result in different errors/warnings, or the same error/warning
appearing multiple times.
HTH,
- Andrew
--
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham
- Replies:
- Re: Sequencer news: latest snapshot J. Lewis Muir
- References:
- Sequencer news: latest snapshot Benjamin Franksen
- Re: Sequencer news: latest snapshot Andrew Johnson
- Re: Sequencer news: latest snapshot Benjamin Franksen
- Navigate by Date:
- Prev:
RE: Newport XPS and Motor record matthew.pearson
- Next:
Re: Newport XPS and Motor record Pete Jemian
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Sequencer news: latest snapshot Benjamin Franksen
- Next:
Re: Sequencer news: latest snapshot J. Lewis Muir
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|