[pseudo,2/3] Makefile.in: Use ARCH_FLAGS instead of -m32 and -m64

Gcc on Loongarch does not support this -m32 and -m64 options.
we can use the $(ARCH_CLAGS) variable instead.

Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
---
 Makefile.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

On Sun, 2025-03-09 at 14:00 +0800, Xiaotian Wu via lists.yoctoproject.org wrote:
> Gcc on Loongarch does not support this -m32 and -m64 options.
> we can use the $(ARCH_CLAGS) variable instead.
> 
> Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
> ---
>  Makefile.in | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile.in b/Makefile.in
> index 48fdbd2..0bb8a88 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -157,10 +157,10 @@ pseudo_wrappers.o: $(GUTS) pseudo_wrappers.c pseudo_wrapfuncs.c pseudo_wrapfuncs
>  	$(CC) -fno-strict-aliasing $(CFLAGS) $(CFLAGS_PSEUDO) -D_GNU_SOURCE -c -o pseudo_wrappers.o pseudo_wrappers.c
>  
>  offsets32:
> -	$(CC) -m32 -o offsets32 offsets.c
> +	$(CC) $(ARCH_FLAGS) -o offsets32 offsets.c
>  
>  offsets64:
> -	$(CC) -m64 -o offsets64 offsets.c
> +	$(CC) $(ARCH_FLAGS) -o offsets64 offsets.c
>  
>  $(PSEUDO_PROFILE): pseudo_profile | $(BIN)
>  	cp pseudo_profile $(BIN)

The whole point of those lines is to generate 64 and 32 bit versions of
those files. A single ARCH_FLAGS value will not do that and it would
break their existing usage.

Since these targets aren't actually referenced anywhere I can see, I'm
wondering how you ran into this in the first place?

This wouldn't work on Arm either but we're not running into it in
normal build usage.

Cheers,

Richard

On 3/13/25 10:54 AM, Richard Purdie via lists.yoctoproject.org wrote:
> On Sun, 2025-03-09 at 14:00 +0800, Xiaotian Wu via lists.yoctoproject.org wrote:
>> Gcc on Loongarch does not support this -m32 and -m64 options.
>> we can use the $(ARCH_CLAGS) variable instead.
>>
>> Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
>> ---
>>   Makefile.in | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile.in b/Makefile.in
>> index 48fdbd2..0bb8a88 100644
>> --- a/Makefile.in
>> +++ b/Makefile.in
>> @@ -157,10 +157,10 @@ pseudo_wrappers.o: $(GUTS) pseudo_wrappers.c pseudo_wrapfuncs.c pseudo_wrapfuncs
>>   	$(CC) -fno-strict-aliasing $(CFLAGS) $(CFLAGS_PSEUDO) -D_GNU_SOURCE -c -o pseudo_wrappers.o pseudo_wrappers.c
>>   
>>   offsets32:
>> -	$(CC) -m32 -o offsets32 offsets.c
>> +	$(CC) $(ARCH_FLAGS) -o offsets32 offsets.c
>>   
>>   offsets64:
>> -	$(CC) -m64 -o offsets64 offsets.c
>> +	$(CC) $(ARCH_FLAGS) -o offsets64 offsets.c
>>   
>>   $(PSEUDO_PROFILE): pseudo_profile | $(BIN)
>>   	cp pseudo_profile $(BIN)
> 
> The whole point of those lines is to generate 64 and 32 bit versions of
> those files. A single ARCH_FLAGS value will not do that and it would
> break their existing usage.
> 
> Since these targets aren't actually referenced anywhere I can see, I'm
> wondering how you ran into this in the first place?
> 
> This wouldn't work on Arm either but we're not running into it in
> normal build usage.

The offset program is specifically for (from docs/pseudo_ipc):

32/64 bit:  This structure should have the same offsets for every element,
including path, on both 64-bit and 32-bit machines.  (Check with 'offsets.c'.)
It is *not* an error if sizeof(pseudo_msg_t) is different; the padding
happens after the path element.  (Note:  This is contrary to C99, TC1, but is
correct according to the current standard.  Anyway, gcc's always done it this
way.)  The data written are always pathlen + offsetof(pseudo_msg_t, path),
and that's correct.

So really it's just a utility to verify that IF your architecture has 32 and 64 
bit variants, that you can ensure that the data structure is the same for both. 
On ARM this _might_ be useful, but I don't think anyone is really running a 
combination 32-bit and 64-bit system.  Same with other architectures (PPC/MIPS/etc.)

Thus the existing implementation is fine, unless someone has a specific workflow 
for a specific architecture where we need to use the tool to verify IPC 
compatibility at runtime.

--Mark


> Cheers,
> 
> Richard
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#1202): https://lists.yoctoproject.org/g/yocto-patches/message/1202
> Mute This Topic: https://lists.yoctoproject.org/mt/111597330/3616948
> Group Owner: yocto-patches+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13201099/3616948/947757854/xyzzy [mark.hatle@kernel.crashing.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>