Experimental Physics and
Industrial Control System

"Pelaia II, Tom" <[email protected]> · Tue, 28 Jun 2011 08:31:53 -0400

Along the lines of your suggestion; an EPICS_HOST_ARCH of darwin-x86+x86_64 sounds reasonable for me, and it should also create soft links for darwin-x86 and darwin-x86_64 for compatibility with existing binaries linked to those libraries and paths for execution. For example, $(EPICS_BASE)/lib would like like:
	darwin-x86
	darwin-x86_64
	darwin-x86+x86_64
where darwin-x86 and darwin-x86_64 are soft links to the darwin-x86+x86_64 directory of universal binaries, and the bin directory would look similarly.

On Jun 27, 2011, at 5:09 PM, Benjamin Franksen wrote:

> Am Montag, 27. Juni 2011, um 18:12:11 schrieb J. Lewis Muir:
>> On 6/27/11 7:48 AM, Benjamin Franksen wrote:
>>>> 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?
>> 
>> That's correct.  For example, if I have EPICS_HOST_ARCH set to
>> "linux-x86" in my environment and ARCH_CLASS set to "i386
>> x86_64" in configure/os/CONFIG_SITE.Common.darwin-x86 in EPICS
>> Base, then when I do make in seq-snapshot-2011-06-24, the only
>> O.* directories in src/seq are O.Common and O.darwin-x86.  So,
>> the O.darwin-x86 contains "fat" object files, libraries, or
>> binaries for both i386 and x86_64.
> 
> I must admit that I went into this discussion w/o any idea what "fat binary"
> means. I know better now, and I understand the problem: with fat binaries one
> has different target architectures inside a single binary. However, could we
> not create a separate pseudo target architecture for such fat binaries? Maybe
> with another separator character; I think '+' would be fine (and self-
> explaining), so that we would have e.g.
> 
>  T_A = darwin-x68+x69_64+pps
> 
>>> Could I test the value of ARCH_CLASS
>>> in the Makefile to decide whether a test should fail or not?
>> 
>> That might work, but maybe not in the way you think.  Say I
>> specify a 32-bit architecture *and* a 64-bit architecture in
>> ARCH_CLASS (e.g. i386 and x86_64).  In this case, I think the
>> test would actually pass when building the i386 machine code but
>> fail when building the x86_64 machine code.  As Andrew noted,
>> the EPICS build system does not invoke gcc for each ARCH_CLASS,
>> that's happening automatically behind the scenes, so I think you
>> would just see failures when building because the fat binary
>> includes the x86_64 machine code.  And maybe that's fine?  If a
>> fat binary (or library) would contain code that would be broken
>> if run on a particular architecture, then fail even though the
>> code would actually be OK for some of the architectures (i.e.
>> i386 in this example).
> 
> Yes, that was the idea. However, with the current build rules for TESTPRODUCTs
> I see no way to communicate the distinction from the Makefile to the test
> script. By parsing the last part of the cwd I could find out the T_A, and if we
> adopted the above proposal, I could match it with '64' inside the test
> script...
> 
> Cheers
> Ben
> 
> ________________________________
> 
> Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
> 
> Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.
> 
> Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
> Geschäftsführer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Dr. Ulrich Breuer
> 
> Sitz Berlin, AG Charlottenburg, 89 HRB 5583
> 
> Postadresse:
> Hahn-Meitner-Platz 1
> D-14109 Berlin
> 
> hxxp://www.helmholtz-berlin.de
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System