Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Mon, 27 Jun 2011 11:29:19 -0500

On 6/27/11 10:21 AM, Andrew Johnson wrote:
> 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.

On a side note, I don't even use the fat binary capability.  I
just set ARCH_CLASS to match my CPU architecture.  So I'd be
fine if the EPICS core developers wanted to drop the fat binary
capability to remove this confusion/problem.  I'm not saying
it's a bad feature, though; I think it's actually nice that the
EPICS build system supports it.  But I'm just saying that if, in
the interest of simplifying the build system or checks like what
Ben is trying to do, I'd be OK if support for fat binaries was
dropped.

On a second side note, I guess Darwin is the only EPICS platform
where fat binaries are supported right now.  There is FatELF
<http://icculus.org/fatelf/>, though.  Maybe sometime down the
line this will become mainstream, in which case we'd have the
same problem on Linux that we are having now for Darwin.

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System