Re: Issue transfering double over the network on x86_64/arvm8

Benjamin Bertrand via omniORB-list <[email protected]> Wed, 15 Feb 2023 12:36:41 +0000
Newsgroups gmane.comp.corba.omniorb.user
Message-ID <[email protected]>

On 2023-02-11, 20:18, "Duncan Grisby" <[email protected] <mailto:[email protected]>> wrote:

>>
>> I have been cross-compiling omniorb for Apple M1 and we haven't seen
>> that issue.
>
>
> Maybe the cross-compiler does set the __VFP_FP preprocessor symbol.

I looked more to understand what is happening.
When cross-compiling I use "configure --host=arm64-apple-darwin20.0.0 --build=x86_64-apple-darwin13.4.0".
I get:
checking build system type... x86_64-apple-darwin13.4.0
checking host system type... aarch64-apple-darwin20.0.0

__arm__ isn't set. I have __arm64__ set by clang.
So it never goes into that block:

#if defined(__arm__)
-#  if defined(__armv5teb__) || defined(__VFP_FP__)
+#  if defined(__armv5teb__) || defined(__VFP_FP__) || defined(__aarch64__)
#    define NO_OMNI_MIXED_ENDIAN_DOUBLE
#  else
#    define OMNI_MIXED_ENDIAN_DOUBLE

When compiling natively on M1, the host system type is set to `uname -p`-apple-darwin${UNAME_RELEASE} for Darwin (by config.guess). And `uname -p` returns "arm".
Is that correct? Or should arm64/aarch64 be used for Apple M1?

Can I trust the cross-compilation I did? Or are some changes required for M1 support?

Thanks

Benjamin

_______________________________________________
omniORB-list mailing list
[email protected]
https://www.omniorb-support.com/mailman/listinfo/omniorb-list