[OpenSIPS-Users] Compiling for arm v7

Micael m8847 at abc.se
Wed Jan 5 14:49:21 UTC 2022


So, in short, what I had to do to cross compile for armv7a using GCC 10.


1. Remove the section in Makefile.defs that tries to detect the arm 
compiler version, since it is outdated afaict. This could of course be 
fixed to also include newer GCC versions in the test. But you guys know 
more about the history here, and if it is worth the effort. GCC stayed 
still in versioning for a long while, and then it kind of exploded.

2. For armv7a, also in Makefile.defs, change the macro test from 
__ARM_ARCH_7__ to __ARM_ARCH_7A__ (this could probably be added as a 
secondary test instead, since it is a rather clean test).

3. Add -marm to CC options

4. Edit modules/tls_wolfssl/Makfile, adding --host=arm
There's a good error message in the wolfssl output, so it did not take 
too long to figure out this.


In my case, I used these options (again, gcc 10);
CC -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -marm

I don't think they are all needed, but I include them as a 'known good' 
setup. :)


Note;
I have not yet tested anything really, but the outlook is good.

Thanks,
  Micael



On 2022-01-05 14:53, Bogdan-Andrei Iancu wrote:
> Guys,
> 
> if you went thru all the pain of getting to the bottom of this, should 
> we document somewhere how this cross compiling should be done? to spare 
> some future pain of other users :).
> 
> 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/5/22 3:42 PM, Micael wrote:
>>
>> 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
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users




More information about the Users mailing list