Re: [OpenSIPS-Users] Compiling for arm v7

[Bogdan-Andrei Iancu]

nice job @razvan !

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS eBootcamp 2021
  https://opensips.org/training/OpenSIPS_eBootcamp_2021/

On 1/12/22 1:26 PM, Răzvan Crainea wrote:

Hi, all!

I've documented this as a tutorial[1]. Feel free to add your 
additional experience there. If you cannot edit the Wiki page, do let 
me know.


[1] https://www.opensips.org/Documentation/Tutorials-CrossCompile#toc1

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 1/5/22 18:27, Ovidiu Sas wrote:

All this should go in the wiki, maybe on a dedicated section.

-ovidiu

On Wed, Jan 5, 2022 at 09:50 Micael > wrote:



    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 ", 
instead of

   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 , host architecture 
  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'
 

Re: [OpenSIPS-Users] Compiling for arm v7

[Răzvan Crainea]

Hi, all!

I've documented this as a tutorial[1]. Feel free to add your additional 
experience there. If you cannot edit the Wiki page, do let me know.


[1] https://www.opensips.org/Documentation/Tutorials-CrossCompile#toc1

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 1/5/22 18:27, Ovidiu Sas wrote:

All this should go in the wiki, maybe on a dedicated section.

-ovidiu

On Wed, Jan 5, 2022 at 09:50 Micael mailto:m8...@abc.se>> 
wrote:



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 ", instead of
   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 , host architecture 
  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' 

Re: [OpenSIPS-Users] Compiling for arm v7

[Ovidiu Sas]

All this should go in the wiki, maybe on a dedicated section.

-ovidiu

On Wed, Jan 5, 2022 at 09:50 Micael  wrote:

>
> 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 ", instead of
>   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 , host architecture 
>  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'
> 
> 
> 

Re: [OpenSIPS-Users] Compiling for arm v7

[Micael]

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 ", instead of 
 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 , host architecture 
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. 

Re: [OpenSIPS-Users] Compiling for arm v7

[Bogdan-Andrei Iancu]

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 ", instead of 
 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 , host architecture 
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
   

Re: [OpenSIPS-Users] Compiling for arm v7

[Micael]

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 ", instead of  
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 , host architecture 
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 

Re: [OpenSIPS-Users] Compiling for arm v7

[Răzvan Crainea]

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 ", instead of  
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 , host architecture 
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 

Re: [OpenSIPS-Users] Compiling for arm v7

[Micael]

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 ", instead of  
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 , host architecture 
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 

Re: [OpenSIPS-Users] Compiling for arm v7

[Răzvan Crainea]

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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Compiling for arm v7

[Bogdan-Andrei Iancu]

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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Compiling for arm v7

[Micael]

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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users