Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 27 Jun 2011 10:21:00 -0500

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System