[OpenSIPS-Users] Compiling for arm v7

Micael m8847 at abc.se
Wed Jan 5 13:42:15 UTC 2022


Hi again Răzvan,

Yes!! That was the final missing bit of the puzzle!

Everything compiles just fine now!


(I had to also make a minor change in wolfssl/Makefile, adding "–host=arm")


Many thanks for your help,

  Micael




On 2022-01-05 13:23, Răzvan Crainea wrote:
> Hi, Micael!
> 
> Can you try to add `-marm` in your CC_EXRTA_FLAGS?
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 
> On 1/5/22 12:19, Micael wrote:
>>
>> Hi Răzvan,
>>
>> Thanks, with your input I learned more about what is happening!
>>
>> So I tried you suggestion and variants of it, but it gave the same 
>> result. So I grep'd the CC_ARCH, and found in Makefile.defs that it is 
>> overwritten by a compiler predefined macro test (__ARM_ARCH_7__).
>> I checked my compiler (gcc 10), and it has __ARM_ARCH_7A__ set.
>> So I changed Makefile.defs into testing against that, and that changed 
>> things.
>> First of all, I now see "Target architecture <arm7>", instead of <arm> 
>> when compiling.
>>
>> But then I arrive into the next problem, I guess this is the same code 
>> (fastlock.h). But now I'm getting into deep water, I suspect the 
>> assembler code needs some TLC?
>>
>>
>> $ make
>> Target architecture <arm7>, host architecture <x86_64>
>> Compiling action.c
>> /tmp/ccrHaC9i.s: Assembler messages:
>> /tmp/ccrHaC9i.s:145: Error: thumb conditional instruction should be in 
>> IT block -- `strexeq r3,r1,[r2]'
>> make: *** [Makefile.rules:28: action.o] Error 1
>>
>>
>> I tried to test with different thumb and interwork options, but that 
>> did not change anything.
>>
>>
>> For reference, I added -v to see exactly which flags where enabled, on 
>> the build.
>>
>> COLLECT_GCC_OPTIONS= '-mthumb-interwork' '-mfloat-abi=hard' 
>> '-mfpu=neon' '-v' '-g' '-I' 
>> '/volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include' 
>> '-D' 'PKG_MALLOC' '-D' 'SHM_MMAP' '-D' 'USE_MCAST' '-D' 
>> 'DISABLE_NAGLE' '-D' 'STATISTICS' '-D' 'HAVE_RESOLV_RES' '-D' 
>> 'F_MALLOC' '-D' 'Q_MALLOC' '-D' 'HP_MALLOC' '-D' 'DBG_MALLOC' '-D' 
>> 'HAVE_STDATOMIC' '-D' 'HAVE_GENERICS' '-D' 'NAME="opensips"' '-D' 
>> 'VERSION="3.2.4"' '-D' 'ARCH="arm7"' '-D' 'OS="linux"' '-D' 
>> 'COMPILER="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc 
>> 10.2.1"' '-D' '__CPU_arm7' '-D' '__OS_linux' '-D' '__SMP_yes' '-D' 
>> 'CFG_DIR="./test//etc/opensips/"' '-D' 'VERSIONTYPE="git"' '-D' 
>> 'THISREVISION="50407d340"' '-D' 'FAST_LOCK' '-D' 'ADAPTIVE_WAIT' '-D' 
>> 'ADAPTIVE_WAIT_LOOPS=1024' '-D' 'HAVE_GETHOSTBYNAME2' '-D' 
>> 'HAVE_UNION_SEMUN' '-D' 'HAVE_SCHED_YIELD' '-D' 'HAVE_MSG_NOSIGNAL' 
>> '-D' 'HAVE_MSGHDR_MSG_CONTROL' '-D' 'HAVE_ALLOCA_H' '-D' 'HAVE_TIMEGM' 
>> '-D' 'HAVE_EPOLL' '-D' 'HAVE_SIGIO_RT' '-D' 'HAVE_SELECT' '-c' '-o' 
>> 'action.o' '-mthumb' '-mtls-dialect=gnu' '-march=armv7-a+simd'
>>
>> /opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.2.1/../../../../arm-none-linux-gnueabihf/bin/as 
>> -v -I 
>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include 
>> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -meabi=5 
>> -o action.o /tmp/ccZHK18t.s
>> GNU assembler version 2.35.1 (arm-none-linux-gnueabihf) using BFD 
>> version (GNU Toolchain for the A-profile Architecture 10.2-2020.11 
>> (arm-10.16)) 2.35.1.20201028
>>
>>
>> Many thanks,
>>    Micael
>>
>>
>> On 2022-01-05 09:25, Răzvan Crainea wrote:
>>> Hi, Micael!
>>>
>>> It is not the compiler that generates the swp/swpb instructions, but 
>>> our locking code for backwards compatibility ARM versions. It is 
>>> using it because it does not properly detect the target architecture 
>>> (armv7), but a generic (older) ARM version.
>>> I see that in your environment you are exporting the CPU variable, 
>>> which is not actually really used in the build.
>>> I'd suggest you try to export the `CC_ARCH` variable 
>>> (`CC_ARCH=armv7`) - this should set the proper CPU type.
>>>
>>> Let us know how this goes.
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>>
>>> On 1/3/22 18:18, Bogdan-Andrei Iancu wrote:
>>>> Hi Micael and Happy New Year ;)
>>>>
>>>> This is more an cross-compiling issue. The arm v6 and 7 obsoleted 
>>>> the swp/swpb instructions - this is what the warning are saying. The 
>>>> problem is that your compiler is generating asm code with those 
>>>> instruction; and the warnings are reported by assembler (which knows 
>>>> that those instructions are not valid).
>>>>
>>>> I'm not a cross-compiling export (not even closer :P), but I guess 
>>>> you are passing some wrong compiling flags, leading to this conflict 
>>>> here.
>>>>
>>>> Best regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>>
>>>> OpenSIPS Founder and Developer
>>>>    https://www.opensips-solutions.com
>>>> OpenSIPS eBootcamp 2021
>>>>    https://opensips.org/training/OpenSIPS_eBootcamp_2021/
>>>>
>>>> On 1/1/22 11:48 AM, Micael wrote:
>>>>> Hi all,
>>>>>
>>>>> (Happy New Year!)
>>>>>
>>>>> I am trying to cross compile 3.2.4 for armv7. Now, I'm new to 
>>>>> opensips,
>>>>> so I have no previous experience to fall back on..
>>>>>
>>>>> In short: I have issues, getting this warning when compiling
>>>>> "swp{b} use is deprecated for ARMv6 and ARMv7"
>>>>>
>>>>>
>>>>> What I have done is:
>>>>> export 
>>>>> CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc 
>>>>>
>>>>> -I 
>>>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include"
>>>>>
>>>>>
>>>>> export LD_EXTRA_OPTS="-L 
>>>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib"
>>>>>
>>>>> export 
>>>>> CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc 
>>>>> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon"
>>>>>
>>>>> export CPU=armv7a
>>>>>
>>>>>
>>>>> I then had to remove the following section in Makefile.defs, 
>>>>> otherwise it would add strongarm1100 as cpu.
>>>>>
>>>>> ---8<---------8<------
>>>>> ifeq    ($(CC_CLASS), 4.x)
>>>>>         CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize
>>>>> else
>>>>>     #if gcc 3.0+
>>>>> ifeq    ($(CC_CLASS), 3.x)
>>>>>         CFLAGS+= -mcpu=strongarm1100
>>>>> else
>>>>> ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5])
>>>>> $(warning             Old gcc detected ($(CC_SHORTVER)), use  gcc 
>>>>> 3.0.x \
>>>>>     for better results)
>>>>>
>>>>>                     CFLAGS+=
>>>>> else
>>>>>                 #really old version
>>>>> $(warning            You are using an old and unsupported gcc \
>>>>>                      version ($(CC_SHORTVER)), compile at your own 
>>>>> risk!)
>>>>>
>>>>> endif            # CC_CLASS, 2.9x
>>>>> endif            # CC_CLASS, 3.x
>>>>> ---8<---------8<------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Once I have done that, everything compiles, but with one and the 
>>>>> same warning (lots, and lots of them);
>>>>>
>>>>>
>>>>> e.g.:
>>>>>
>>>>> Compiling ip_addr.c
>>>>> /tmp/ccj7cheW.s: Assembler messages:
>>>>> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7
>>>>> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7
>>>>> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7
>>>>> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7
>>>>> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7
>>>>> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7
>>>>> Compiling ipc.c
>>>>> Compiling main.c
>>>>> Compiling map.c
>>>>> /tmp/cc6q8n3v.s: Assembler messages:
>>>>> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7
>>>>> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7
>>>>> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7
>>>>> Compiling md5.c
>>>>> Compiling md5utils.c
>>>>>
>>>>>
>>>>> I guess I must not be the only one compiling for arm, so I hope 
>>>>> someone can point me closer to whats wrong.
>>>>>
>>>>>
>>>>> Any help appreciated,
>>>>>   Micael
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users




More information about the Users mailing list