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
>
>
- References:
- Sequencer news: latest snapshot Benjamin Franksen
- Re: Sequencer news: latest snapshot Benjamin Franksen
- Re: Sequencer news: latest snapshot J. Lewis Muir
- Re: Sequencer news: latest snapshot Benjamin Franksen
- Navigate by Date:
- Prev:
Re: Sequencer news: latest snapshot Pelaia II, Tom
- Next:
Re: Newport XPS and Motor record John Dobbins
- 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 Andrew Johnson
- 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
|